Re: led support in mac80211 and drivers

["John W. Linville" <linville@tuxdriver.com>]

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@vger.kernel.org

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel

-- 
John W. Linville
linville@tuxdriver.com