On Jan 17, 2008 5:46 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > I'm wondering if this shouldn't simply be a driver decision and mac80211 > exports an RXon LED that is always "on" for as long as receive is > running (whatever that means, please specify!) What we do is translate throughputs - to 8 patterns if I remember correctly. Only when the throughput cross threshold level NIC is disturbed with changing blinking pattern. > Or you need to define blink patterns with the core LED framework. Not for traffic but for example some laptops vendors wants slow blink in unassociated state some wants led to be off. The problem is that led behavior in clean design would be defined by trigger. So I would prefer to put flexibility of LED behavior in that level. > > > > > - Mapping to what led is this behavior mapped > > That's trivially specified in sysfs. b43 (since it was mentioned > already) has some special logic to set up defaults coming from EEPROM. > > > > > > - One behavior might be mapped to single led. Then we need to know > > > > > what trigger take precedences. > > That (multiple behaviours on a single LED) is impossible in the current > LED framework. Most of todays laptop has only one led for Wifi that's a problem. > > > > 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 ;) > > No, that sounds like a bad idea. We actually want the flexibility here, > I could for example use the front LED on my powerbook as a wireless > association LED if I wanted. We want to use the LED framework and if > that means three LEDs in your driver then so be it. I agree it has a lot of benefits to use LED framework, but it can be pushed to driver or some module. Unfortunately I'm not sure myself Tomas > johannes > - 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
