Bug 618232 - ath5k: rfkill light changes from on to off and back on spasmodically
Summary: ath5k: rfkill light changes from on to off and back on spasmodically
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-26 13:30 UTC by Kieran Clancy
Modified: 2010-08-06 13:35 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-05 17:28:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
0001-ath5k-add-led_disable-module-option.patch (1.35 KB, application/octet-stream)
2010-07-28 16:32 UTC, John W. Linville
no flags Details

Description Kieran Clancy 2010-07-26 13:30:53 UTC
Description of problem:
I just upgraded from F11 to F13, and I am now having a problem where the rfkill prominent light on my laptop (blue for wireless enabled, red for wireless disabled) flickers between states all the time when the wireless is on. The wireless does not actually turn off in this time, and udev doesn't register any change while it's flickering.

In F11 the rfkill functionality didn't work for my laptop at all (the system didn't recognise the button being pressed and the light was always red for "off", but the wireless worked without problems).

Now in F13, I am beginning to find this very distracting after just a few hours. The blue light is very bright and it keeps flashing on and off in no particular pattern. It's still red most of the time too, so it's not properly reporting the wireless state. If I press the rfkill button, the system now detects that the wireless is disabled, and the light will remain in whatever state it was in when I pressed it (no flickering).

So, my suspicion is that somehow the system has confused the rfkill indicator with a wireless network indicator (which might flash during data transfer on some laptops). Is there any way to debug this?

Version-Release number of selected component (if applicable):
kernel-2.6.33.6-147.fc13.x86_64

Steps to Reproduce:
1. Turn on wireless and connect to a network
  
Actual results:
Watch the prominent light change colour annoyingly.

Expected results:
The light should be blue when the wireless is on, and red when the wireless is off. No flickering.

Additional info:
Laptop: HP Compaq Presario CQ61
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
	Subsystem: Hewlett-Packard Company Device 137b
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at d3500000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
	Capabilities: [60] Express Legacy Endpoint, MSI 00
	Capabilities: [90] MSI-X: Enable- Count=1 Masked-
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Kernel driver in use: ath5k
	Kernel modules: ath5k

Comment 1 John W. Linville 2010-07-26 14:36:39 UTC
Looks like your laptop is hitting the information from the patch below:

commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d
Author: Marcos Chaparro <nitrousnrg>
Date:   Mon Aug 24 23:00:31 2009 -0400

    ath5k: add led pin configuration for compaq c700 laptop
    
    With this patch, a compaq c700 can turn on the wifi led.
    The array of compatible devices now includes the hardware
    present in this computer, as well as the led pin and
    polarity.
    
    Signed-off-by: Marcos Chaparro <nitrousnrg>
    Signed-off-by: Bob Copeland <me>
    Signed-off-by: John W. Linville <linville>

diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index 876725f..b767c3b 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -69,6 +69,8 @@ static const struct pci_device_id ath5k_led_devices[] = {
        { ATH_SDEVICE(PCI_VENDOR_ID_AZWAVE, 0x1026), ATH_LED(3, 0) },
        /* IBM ThinkPad AR5BXB6 (legovini.unipd.it) */
        { ATH_SDEVICE(PCI_VENDOR_ID_IBM, 0x058a), ATH_LED(1, 0) },
+       /* HP Compaq C700 (nitrousnrg) */
+       { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
        /* IBM-specific AR5212 (all others) */
        { PCI_VDEVICE(ATHEROS, PCI_DEVICE_ID_ATHEROS_AR5212_IBM), ATH_LED(0, 0) },
        { }

Bob, I don't suppose there is anyway to easily experiment with these LED settings (i.e. without compiling kernels)?

Kieran, have you used this device with another OS?  Does it flash a different light for activity there?  Or none at all?  Is this light the only one flashing?

Comment 2 John W. Linville 2010-07-26 14:37:48 UTC
Ooops!  Forgot to Cc Bob...

Comment 3 Kieran Clancy 2010-07-26 14:43:05 UTC
In Windows Vista it is red when wireless is disabled/disconnected and blue when wireless is connected. It never flickers between red and blue while connected. There is no LED on the laptop to indicate wireless transfer activity.

Comment 4 John W. Linville 2010-07-28 16:32:43 UTC
Created attachment 435068 [details]
0001-ath5k-add-led_disable-module-option.patch

Comment 5 John W. Linville 2010-07-28 17:31:55 UTC
F-13 test kernel w/ above patch is available here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2356195

To use it, create a file named /etc/modprobe.d/ath5k.conf with the following single line:

options ath5k led_disable=1

Then reboot into the new kernel installed from the link above (once the build finishes).  Does this stop the annoying blink?

Comment 6 Bob Copeland 2010-07-29 12:05:28 UTC
As mentioned on the ML we can do without a modparam here, instead you can do:

$ echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"

and same for the rx trigger.  That will disable the LED completely, and you can also set the current value of the led through the brightness file (I think)... the LEDs are binary so use either 0 or max_brightness.

Both triggers are connected to the same gpio in ath5k, so you'll have to modify both triggers or turn one off.  There is a second gpio for the rfkill; I don't believe we control how the LED is displayed there, just whether it is on or off.

Also of note, you can use other mac80211 triggers like 'phy0assoc' or 'phy0radio' if you want to have the led lit only when associated or when rfkill is enabled, etc.  Of course I have not tried, since I don't have any hardware with LEDs.

Oh one other thing: some cards have hardware LEDs which aren't hooked up to the trigger files because the hardware drives them.  It is possible to put these LEDs under software control (madwifi does) but IMO it's silly to make the host strobe the gpio if the card can do it.  This is mostly on older pcmcia kit though.

Comment 7 Bob Copeland 2010-07-29 12:09:59 UTC
RE the OP, to me it sounds like rfkill and led gpios are separate but this particular laptop uses it to indicate rfkill state.  So I think you can just set one of the trigger files to phy0radio and turn off the other one.

Comment 8 Kieran Clancy 2010-07-29 16:21:53 UTC
John, thank you for taking the time to build a custom kernel with that patch. Since Bob's suggestion (thanks Bob) works, I didn't test it at this point.

Bob, I don't fully understand your comment; what is gpio/mac80211/phy0assoc/phy0radio/etc?

Echoing 'none' to both triggers makes the light stop flickering.

I think you may have explained it (but I didn't understand), but why doesn't the rfkill light change colour anymore?

Lastly, it's all fine for me to put a couple of lines in an init script to set these to 'none', but there's obviously a bug in that the kernel is detecting all HP ath5k devices with the same id as having a wireless network indicator when in fact it is an rfkill indicator. Is it possible to differentiate in the kernel between ath5k devices with an rfkill LED and ones with transfer LEDs?

Comment 9 Bob Copeland 2010-07-30 02:05:37 UTC
(In reply to comment #8)
> John, thank you for taking the time to build a custom kernel with that patch.
> Since Bob's suggestion (thanks Bob) works, I didn't test it at this point.
> 
> Bob, I don't fully understand your comment; what is
> gpio/mac80211/phy0assoc/phy0radio/etc?

Okay I'll try to clarify:

- gpio = general purpose I/O pins, i.e. the wire coming from the wifi mac chip to somewhere on the pcie connector which is then hooked up to the LED on the case in the laptop.  There may be multiple gpios with different functions; e.g. ath5k supports a write-able gpio for setting the rfkill state, and another one for setting the LED state.  Though theoretically there might be multiple LEDs, or a separate rfkill LED, we really only support one single LED.

- mac80211 = the Linux kernel wireless stack, which sits above ath5k.  It provides the basic LED interface that wireless drivers can use.

Each exposed LED has an LED trigger, which is represented by the file in sysfs and represents the event that turns the LED on or off.  For ath5k, since we just support a single LED, both rx and tx triggers are set up to toggle the LED when packets are received and transmitted.

> I think you may have explained it (but I didn't understand), but why doesn't
> the rfkill light change colour anymore?

Think of the rfkill switch and the rfkill LED as separate functions.  We're
obviously strobing the rfkill LED for rx and tx, which doesn't match what Vista does.  I believe you can get a similar-to-Vista behavior by doing:

$ echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"
$ echo phy0radio > "/sys/class/leds/ath5k-phy0::rx/trigger"

In other words, turn one of the triggers off and make the other one operate for radio on/off events.  You can get a list of available triggers by catting the trigger file.

> Is it possible to differentiate in the
> kernel between ath5k devices with an rfkill LED and ones with transfer LEDs?    

This, I don't know.  It would be nice if this info were already available via acpi or something.  We could add another flag for LED function but the pin/polarity table already doesn't scale, so there needs to be a better way than just keeping the table of pci ids...

Comment 10 John W. Linville 2010-08-05 17:28:36 UTC
It sounds like you at least have a solution to tame the LEDs.  Determining if/how to differentiate between laptops on some basis other than PCI IDs seems like an upstream issue to me.

Comment 11 John W. Linville 2010-08-06 13:35:26 UTC
This might be useful for reference:

https://bugzilla.kernel.org/show_bug.cgi?id=16192


Note You need to log in before you can comment on or make changes to this bug.