> > > > So what is needed for led implementation are 3 decision chain > > > > - Activity Trigger (RX, TX, Association, Radio State/RF Kill) mac80211 exports multiple triggers already and could be amended to those that are currently missing. > > > > - Behavior Decision - What is done on each trigger > > > > - Behavior is easy to model - ON, OFF, BLINK(pattern) BLINK(pattern) is currently not defined. Actually, especially since you say later: > > > > 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., 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!) Or you need to define blink patterns with the core LED framework. > > > > - 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. > > > 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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
