led support in mac80211 and drivers
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
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, [email protected]
Thanks,
John
Quoted 99 lines · Tomas Winkler
Quoted 4 lines
Quoted 2 lines
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
Quoted 1 line
of ieee80211_get_*_led_name(), the broadcom B43 wireless driver.
Correct
That
Quoted 4 lines
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.
Quoted 10 lines
Quoted 7 lines
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.
Quoted 11 lines
Quoted 5 lines
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 aieee80211_hwdevice. One single callback that would be called when there's activity or if the state of the device has changed. Maybe something like this:Quoted 7 lines
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 - > LedQuoted 4 lines
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
Quoted 5 lines
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.
Quoted 3 lines
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
Signature · 2 lines
John W. Linville [email protected]
You are right, Thanks for bringing us home :)
Tomas
Quoted 117 lines · John W. Linville
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, [email protected]
Thanks,
John
Quoted 92 lines · Tomas Winkler
Quoted 4 lines
Quoted 2 lines
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
Quoted 1 line
of ieee80211_get_*_led_name(), the broadcom B43 wireless driver.
Correct
That
Quoted 4 lines
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.
Quoted 10 lines
Quoted 7 lines
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.
Quoted 11 lines
Quoted 5 lines
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 aieee80211_hwdevice. One single callback that would be called when there's activity or if the state of the device has changed. Maybe something like this:Quoted 7 lines
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 - > LedQuoted 4 lines
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
Quoted 5 lines
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.
Quoted 3 lines
tom
Quoted 8 lines
-------------------------------------------------------------------------
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel--
John W. Linville
[email protected]
Quoted 9 lines · John W. Linville
Quoted 8 lines · Tomas Winkler
That
Quoted 4 lines
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.
The question rather was: since there is really no user of the led infrastructure that needs the flexibility (the broadcom seems to have the leds on the same bus as the device itself) in the official kernel.. where are these drivers? Are they publicly available? Or are they in custom kernels? I can see the need for such infrastructure, but I don't see any actual users of it...
Quoted 22 lines
Quoted 22 lines
Quoted 5 lines
I thought about having an '
ieee80211_activity_listener' that could subscribe to activity events of aieee80211_hwdevice. One single callback that would be called when there's activity or if the state of the device has changed. Maybe something like this:Quoted 7 lines
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
Quoted 6 lines
Quoted 6 lines
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
I see that the whole wireless led interaction is a delicate matter. It's not easy to understand it fully (in such short time - however hard I try). You wouldn't believe how many times I've rewritten this email ;)
Do you have any numbers about how many platforms have leds on a different bus than the wlan device? Are those notebooks or embedded devices? In case of notebooks, I assume linux doesn't support the leds there, since I haven't found any code in the kernel that would use the mac80211 led subsystem to receive led activity notifications.
The 4965 chip supposedly supports three leds, but my notebook (thinkpad x61t) only has one. Other notebooks/platforms may have two/three. I imagine implementing different led behaviour based on how many leds there are and other platform differences will require lots of code (platform detection etc). And thus getting the led code right for everyone is very difficult. Is that the reason why any of the iwlwifi led patches hasn't been applied yet?
In the iwl4965 driver, implementing led support wholly inside the driver itself seems possible. And platforms that have leds on a different bus still can make their own led-driver and use the mac80211 subsystem to receive led activity notifications. All but the broadcom wireless drivers implement led support is such way. So I think that's the way to go.
In essence, on platforms that have the radio device and leds on the same bus, it's actually easier to implement led support inside the driver and not using the mac80211 led subsystem. The driver has all the needed info to control the leds (device state etc). The mac80211 led subsystem is only useful for platforms where the leds are on a different bus.
I must apologize, there's nothing wrong with the mac80211 led subsystem, it does what it was designed for. It's the many iwlwifi led patches that gave me a bad impression that the mac80211 led subsystem was somehow needed for led support, what a shame :( I'm sorry for the noise.
tom
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
- 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:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- 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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
- 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.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I thought about having an '
ieee80211_activity_listener' that could subscribe to activity events of aieee80211_hwdevice. One single callback that would be called when there's activity or if the state of the device has changed. Maybe something like this:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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
Quoted 3 lines · Johannes Berg
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.
Quoted 1 line
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.
Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- 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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
- 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.
Quoted 13 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I thought about having an '
ieee80211_activity_listener' that could subscribe to activity events of aieee80211_hwdevice. One single callback that would be called when there's activity or if the state of the device has changed. Maybe something like this:Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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 ;)
Quoted 4 lines
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
Quoted 2 lines
johannes
Quoted 4 lines
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.
Huh ok. I suppose you want a throughput notification from mac80211 for that. And you want to define blinking within the LED framework, rather than just intensity.
Quoted 6 lines
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.
I'm not so sure. I think it'd make more sense to define state triggers (associated) and do whatever behaviour based on the state. Dunno.
Quoted 4 lines
Most of todays laptop has only one led for Wifi that's a problem.
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
Maybe an intermediate level in the LED framework could be written, something that itself has multiple LED "inputs" (LED devices) and takes multiple triggers, translating it into a new trigger that the single laptop wifi LED can be bound to. Sounds like too much complexity though...
I don't really care much, but I definitely don't want to add new callbacks for LEDs to mac80211. If you need something special please do it within the LED framework.
johannes
Quoted 7 lines · On Thursday 17 January 2008 16:46:22 Johannes Berg wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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!)
I read this thread multiple times, but I don't get where the problem is. Why don't you simply implement this in the driver:
When LED didn't change software state for X jiffies, switch the auto-blinking LED in the hardware off. Switch it on if it's off in hardware and there's a software state transition.
Where's the problem? This is trivial to implement.
Signature · 1 line
Greetings Michael.
Quoted 9 lines · Michael Buesch
Quoted 7 lines · On Thursday 17 January 2008 16:46:22 Johannes Berg wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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!)
Quoted 6 lines
I read this thread multiple times, but I don't get where the problem is. Why don't you simply implement this in the driver:
When LED didn't change software state for X jiffies, switch the auto-blinking LED in the hardware off. Switch it on if it's off in hardware and there's a software state transition.
Where's the problem? This is trivial to implement.
Sure it's simple, even there are few implementations already in the mailing list.. just still missing the flexibility I seek. Tomas
Yes I see this more as a stop gap solution. The fact is that there is a lot of contengency on how the light blinks (and it's understandable). But the feature is so far over due that at this point it's best to have something so the user can know that wireless is on or off.
Quoted 31 lines · Tomas Winkler
Quoted 9 lines · Michael Buesch
Quoted 7 lines · On Thursday 17 January 2008 16:46:22 Johannes Berg wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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!)
Quoted 6 lines
I read this thread multiple times, but I don't get where the problem is. Why don't you simply implement this in the driver:
When LED didn't change software state for X jiffies, switch the auto-blinking LED in the hardware off. Switch it on if it's off in hardware and there's a software state transition.
Where's the problem? This is trivial to implement.Sure it's simple, even there are few implementations already in the mailing list.. just still missing the flexibility I seek. Tomas
-------------------------------------------------------------------------
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
Quoted 7 lines
I read this thread multiple times, but I don't get where the problem is. Why don't you simply implement this in the driver:
When LED didn't change software state for X jiffies, switch the auto-blinking LED in the hardware off. Switch it on if it's off in hardware and there's a software state transition.
Where's the problem? This is trivial to implement.
I think the point is that the software LED changes all the time but that's not necessary for the hardware LED because the firmware will blink it. Or something like that anyway.
johannes