Created attachment 26751 [details] lspci's output On my IBM Thinkpad X31 with atheros wlan card, the WLAN LED behaves strangely. actual results: when wlan is switched off via rfkill, the LED is on. when it's switched on, it has no effect (stays on). when wlan is active (transferring, searching, associating etc), the LED sometimes blinks, sometimes is on (solid), sometimes is completely off expected results: for example: on (solid) when wlan is active, blinking if associating OR: flashing when active (transferring, associating, whatever), off when idle/rfkill-ed only when i unload the ath5k module, the LED is switched off.
On kernel 2.6.35 (i assume but didn't verify that this also works on older kernels), this could be fixed (or actually, work-around-ed) as follows: set one LED's trigger to the rfkill of the wlan card. this alone switches the LED on or off when triggering rfkill, unfortunately also off when the card gets active (transferring or receiving data) set the other LED's trigger to phy0radio. this alone switches the LED on when it gets active (that is, exactly then when the above would fail) the result is a almost unnoticeable flicker when it starts transferring (it gets switched off (bug!) and switched on immediately after it), but for me, this is enough. This is how i automated that task: echo 'install ath5k modprobe --ignore-install ath5k; sleep 1; bash /root/flo-setup-wlan-led' > /etc/modprobe.d/flo-ath5k the /root/flo-setup-wlan-led file is attached it finds out the correct rfkill (i have two (bluetooth vs wlan) which have a race-condition), finds the paths to the wlan leds and sets the triggers as described above the above may suggest that i have two LEDs. i have NOT. However, Linux sees two (rx and tx), i dunno why. The real LED can controlled by both "linux-leds". if i switch rx on, the real turns on. if i then switch tx (not rx!) off, it turns off again. Maybe this is related to the bug.
Created attachment 27362 [details] my /root/flo-setup-wlan-led
See a similar report here: https://bugzilla.redhat.com/show_bug.cgi?id=618232 This means there at least two instances of ath5k hardware which have a LED intended to indicate rfkill and not wireless network activity. The kernel needs to do a better job of distinguishing between hardware with an rkfill LED and hardware with a wireless activity LED. In my opinion, it would be better to err on the side of having no working transfer light than having an rfkill light blinking madly. (For example, on my laptop the rfkill light is like 20 lumens and is extremely distracting while blinking.)
NetBSD seems to handle the LED correctly, or at least, with a certain system when i set it up or down, it turns on or off, when i start a wlan search, it blinks. (i find that pretty bright led blinking annoying, but at least netbsd is able to manage it correctly). maybe it may help to look at netbsds code. maybe simply allowing the user to disable automatic control of the led helps. then i could tell him: "ath5k, don't touch the led!" and set the trigger correctly (or set brightness manually, which does not matter, as i need a custom script to make my wlan button working at all) on older kernels (2.6.26), the led worked as transfer indicator, and was not very bright, as it was flashing extremely quickly. the led was not exposed. is such a PWM possible to implement without problems in software, or would that cause high power consumption (due to interrupt wakeups etc)? because then it would be possible, for example, to turn it "half-on" for "rfkill on" and "full-on" for transmitting or so...
Unless/until laptop vendors want to submit their own patches, I think enabling scripts like the one in comment 2 are the best we can do...