Search Linux Wireless

Re: led support in mac80211 and drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You are right, Thanks for bringing us home :)
Tomas

On Jan 16, 2008 10:01 PM, John W. Linville <linville@xxxxxxxxxxxxx> wrote:
> I appreciate that this topic started with discussion of the (long
> overdue) support for LEDs in the iwlwifi drivers.  However at
> this point I think it has strayed sufficiently into the mac80211
> realm that it should be moved to the home of mac80211 development,
> linux-wireless@xxxxxxxxxxxxxxx
>
> Thanks,
>
> John
>
>
> On Wed, Jan 16, 2008 at 08:38:48PM +0200, Tomas Winkler wrote:
> > > > Currently we recognize 4 or 5 pasterns that are implemented and
> > > > switching between them according laptop vendor.
> > >
> > > We = who?
> >
> > Intel
> >
> > Greping through the kernel source revealed only a single user
> > > of ieee80211_get_*_led_name(), the broadcom B43 wireless driver.
> >
> > Correct
> >
> > That
> > > driver switches between different modes based on bus->boardinfo.vendor.
> > > But where are the other modules needing this flexibility? Are they being
> > > developed in private by the companies that make the access points?
> > >
> >
> > Different Laptop vendor and AP vendors. This information might be
> > written in many places, PCI subvendor, in EEROM etc sometimes it has
> > to be supplied from outside.
> >
> >
> > > > So what is needed for led implementation are 3 decision chain
> > > >  - Activity Trigger (RX, TX, Association, Radio State/RF Kill)
> > > >  - Behavior Decision -  What is done on each trigger
> > > >     - Behavior is easy to model - ON, OFF, BLINK(pattern)
> > > >  - Mapping to what led is this behavior mapped
> > > >     - One behavior might be mapped to single led. Then we need to know
> > > > what trigger take precedences.
> > >
> > > Actually, the second and third point can be merged.
> > >
> >
> > Agree Implementation wise might be simpler.
> >
> > > > Actually the major problem I have currently with mac80211 trigger
> > > > implementation RX/TX trigger since Intel's led doesn't have to be
> > > > triggered ON/OFF on each packet, led is capable of blinking itself.,
> > > > therefore I would like to see your patch very much. We probably would
> > > > have to work on flexibility of blinking patterns
> > >
> > > I thought about having an 'ieee80211_activity_listener' that could
> > > subscribe to activity events of a ieee80211_hw device. One single
> > > callback that would be called when there's activity or if the state of
> > > the device has changed. Maybe something like this:
> > >
> > > int (*callback)(... *hw, u8 state, u8 type);
> > >
> > > where 'state' would be a bitmap of scanning/associated/etc and type the
> > > 'type' of activity (transmitting/receiving a frame). The callback then
> > > would decide which leds to activate and how (blinking or not etc). Does
> > > that sound better? At least it would be better than having to register
> > > three leds in each low-level driver ;)
> >
> > I'm not sure it's such big deal to subscribe to led more problem is
> > that I cannot subscribe same led to different triggers
> > so need another level
> > mac80211     | driver
> > Led Trigger ->| Logical Led -> (LED LOGIC/MAPPING) ->  HW LED
> >                     |
> >
> > The problem here is that logic is already defined in Led pattern is
> > already defined int Led Trigger
> >
> > Problem with your approach I cannot reach LEDs that are not connected
> > to NIC's PCIe pins.
> >
> > Other options that uses your idea is
> > mac80211        |  driver
> > mac callback ->| (LED LOGIC) - Led Trigger - > Led
> >
> >
> > > Btw, is there a function that lists all 'struct ieee80211_hw *'? How
> > > does the led driver (external driver, where the leds are on a different
> > > bus and the driver implemented in a different kernel module) get the led
> > > triggers?
> >
> > by name - "wlan0:rx"  for example
> >
> > > Oh, and I read (in the intel driver source) that there is no callback
> > > from the low-level driver into the mac subsystem that would inform it
> > > that rfkill is active... that limitation would be bad in case of the
> > > external led drivers.
> > >
> > That's a gap.
> >
> > > tom
> > >
> > >
> >
>
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Ipw3945-devel mailing list
> > Ipw3945-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
> --
> John W. Linville
> linville@xxxxxxxxxxxxx
>
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux