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
