Tomas Winkler wrote:
> > On 10/17/07, Ian Schram <[email protected]> wrote:
>> >> I do *not* send a led command on each packet. (Unless i made a ho=
rrible
>> >> coding error that I do not see)
>> >>
>> >> I send a led command when on every association event. But that's =
only when
>> >> we actually associate. or hw/sw rfkill is activated, or deassocia=
ted.
>> >>
>> >> The leds for activity: keep a counter, which counts how many time=
s the led
>> >> is triggered from mac80211
>> >> right now this is a multiple of the #packets. A delayed work will=
run
>> >> every 500 ms and translate this
>> >> amount of packets into a blinking rate for the led. When no packe=
ts are
>> >> transeived, the delayed work
>> >> will not be scheduled until new packets are transeived.
> >
> >
> > When no packets are transmitted correct behaviour is steady light=
on.
> >
> > This is quite similar to how the leds work in
>> >> ipwraw, and ipw3945, only there the amount of byters were counted=
in the
>> >> rx and tx path, which
>> >> was then converted to a blinking rate. This information is not av=
ailable
>> >> within the led framework,
>> >> hence i used the amount of led events and translate that into a b=
linking
>> >> rate.
> >
All these comments are on the activity led code. This code is the bulk
of the patch, and proably isn't the nicest solution to the problem.
I could send a stripped down patch, that only registers the association=
led trigger.
This is something that is a lot easier the mac80211_leds way.
This basic functionality of the led being on when associated, is still =
a nice
gimmick imho. Second only to the firmware filename it's the comment i m=
ost
frequently read in irc.. but perhaps i have tunnel vision.
> >
> > I think we can figure out how to do it correctly we already have th=
rouput
> > masurement incorporated in.
> > Second I=B4m not sure that the wrokqueueu is really necessary. I th=
ink that
> > the command can be issued right away.
if i'm not mistaking ratescale has this data, and that there is no prob=
lem
collecting this data from the rx/tx paths. for activity, this is probab=
ly more
efficient and accurate. I just choose to do this the mac80211 way too
>> >>
>> >> I did manage to listen to your comments on my previous patch ;-)
> >
> >
> > I=B4ve just recalled I wrote already once email as this one :) . Y=
eah I
> > didn=B4t read code carefully enough.
> >
> > Actually i believe this to be a crossection of what mac80211_leds e=
xpects,
>> >> and how ipw used to
>> >> do it.
>> >>
>> >> Ian
>> >>
Ian