Bug 618232
Summary: | ath5k: rfkill light changes from on to off and back on spasmodically | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kieran Clancy <clancy.kieran+redhat> | ||||
Component: | kernel | Assignee: | John W. Linville <linville> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 13 | CC: | anton, dougsland, gansalmon, itamar, jonathan, kernel-maint, linville, madhu.chinakonda, me | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-08-05 17:28:36 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Kieran Clancy
2010-07-26 13:30:53 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? Ooops! Forgot to Cc Bob... 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. Created attachment 435068 [details]
0001-ath5k-add-led_disable-module-option.patch
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? 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. 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. 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? (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... 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. This might be useful for reference: https://bugzilla.kernel.org/show_bug.cgi?id=16192 |