On Wednesday 13 December 2006 17:54, Ulrich Kunitz wrote:
> I mean on the other hands we break APIs for four or
> eight bytes and here we spend a whole device strucuture and sysfs
> directory for something the wlan device firmware represents with a
> single bit. To call the housekeeping functions
Michael,
please detach a little bit from LEDs.
A trigger is a generic concept. It doesn't need to have a special
binding to what it triggers. It could be a buzzer, it could be
an LED, it could be text output on an LCD.
So we could have link status change trigger, for which functions
could be reg
On Tuesday 12 December 2006 17:38, Ulrich Kunitz wrote:
> Micheal, how resetting an LED every second is overkill is beyond
> me.
I mean it is overkill in that is more than needed.
> On a USB 2.0 port the available bandwidth is much higher than
> on the air. Notify also that the LED is flip-floppe
On 06-12-11 20:32 Michael Wu wrote:
> On Monday 11 December 2006 17:55, Ulrich Kunitz wrote:
> > I cannot accknowledge this patch. Michael, the LED does not only
> > show the link status, but also indicate that packets are sent,
> > which is done by the firmware. However the LED flags have to be
>
On Monday 11 December 2006 17:55, Ulrich Kunitz wrote:
> I cannot accknowledge this patch. Michael, the LED does not only
> show the link status, but also indicate that packets are sent,
> which is done by the firmware. However the LED flags have to be
> reset every second, because if an odd number
On 06-12-11 00:44 Michael Wu wrote:
> This makes zd1211rw-d80211 register an LED class to control the link LED
> instead of trying to determine when the LED should be on based on the
> current bssid. No default trigger is set since d80211 doesn't currently
> have a link on/off LED trigger.
I cann
