Bug 195563

Created attachment 255987 [details]
DSDT from Asus UX330

From the DSDT, this appears to be asus-nb-wmi related. I suspect:

platform/x86: asus-wmi: Remove quirk_no_rfkill, and related patches may have been the cause, as you suggest. Are you able to assist with testing patches?

Can you attach the results of `dmidecod`?

(In reply to Darren Hart from comment #2)
> From the DSDT, this appears to be asus-nb-wmi related. I suspect:
> 
> platform/x86: asus-wmi: Remove quirk_no_rfkill, and related patches may have
> been the cause, as you suggest. Are you able to assist with testing patches?
> 
> Can you attach the results of `dmidecod`?

The demidecode is attached.
No problem for testing patches.

Created attachment 256237 [details]
demidecode from Asus UX330UA

(In reply to Darren Hart from comment #2)
> From the DSDT, this appears to be asus-nb-wmi related. I suspect:
> 
> platform/x86: asus-wmi: Remove quirk_no_rfkill, and related patches may have
> been the cause, as you suggest. Are you able to assist with testing patches?
> 
> Can you attach the results of `dmidecod`?

In case it could help you, attached are the 2 dsdt 
from the Asus UX31A and UX305FA.

Following the exemple in your e-mail (Also by inspection of the DSDT, the DSTS2 (0x53545344) status for the DEVID_WIRELESS_LED (0x10002) returns 0x50002)

I made a search for 0x53545344 in both dsdt and the result is the same as in
the UX330UA:

If (LEqual (IIA0, 0x00010002))
                    {
                        Return (0x00050002)
                    }

Created attachment 256535 [details]
DSDT from Asus UX31A

Created attachment 256537 [details]
DSDT from Asus UX305FA

Hi

The bug is still present in the 4.12-rc4 kernel

Hi
I think I have the same problem here on an Asus X556UQK:
[    0.000000] DMI: ASUSTeK COMPUTER INC. X556UQK/X556UQK, BIOS X556UQK.312 09/18/2017,
kernel version: 4.13.0-35-generic.

Airplane-mode switching works, but no LED.
How can I help in debugging ? I have experience in C-debugging since 20 years but never did this with Linux-kernel. Now I'm in retirement and have a lot of time.

Wolfram

Hi
The bug is still present in the 4.16-rc1 kernel.

Created attachment 274475 [details]
DSDT from Asus X556UQK

DSDT from Asus X556UQK

The bug is still present in the 4.16-rc3 kernel.

Here what I tried today based on kernel 4.16-rc3:

1. Deactivating the code regarding my hardware (ATK4002) in asus-wmi.c. The result was that the airplane-mode-led was working again but in an inverted mode.

2. Blacklisting module asus-nb-wmi as suggested in <https://wiki.ubuntuusers.de/rfkill/> Here's the result:
It's working like a charm except the LED. And this only with module 'asus-wireless' running.

Inspecting the code of this module I found a change recently made by João Paulo Rechi Vita regarding ATK4002 and the LED. Unfortunately this doesn't work for my Hardware. How can I contact him to do some more testing ?

I did some more debugging of module 'asus-wireless', here the result:
- 'asus_wireless_notify' is called with the correct event (0x88) when changing the airplane-mode.
- 'led_state_set' and 'led_state_update' are never called.
Until now I'm not so deep into this to find out from where they should be called, so I need a little help.

Is someone reading this ?

Wolfram

I did report the very same bug ~1 year ago (ticket 196025) but I got no answer at all, it'd be nice to fix this regression sooner or later.

Long story short:

\_SB_.ASHS.HSWC(0x1) the led turns on, then
\_SB_.ASHS.HSWC(0x2) results in 0

\_SB_.ASHS.HSWC(0x0) the led turns off, then
\_SB_.ASHS.HSWC(0x2) results in 0

OWGS is unreliable and always returns zero.

I did the following change, and got the led working on my notebook:

diff --git a/drivers/platform/x86/asus-wireless.c b/drivers/platform/x86/asus-wireless.c
index d4aeac3477f5..8137a6ac3334 100644
--- a/drivers/platform/x86/asus-wireless.c
+++ b/drivers/platform/x86/asus-wireless.c
@@ -111,12 +111,23 @@ static void led_state_set(struct led_classdev *led, enum led_brightness value)
 static void asus_wireless_notify(struct acpi_device *adev, u32 event)
 {
        struct asus_wireless_data *data = acpi_driver_data(adev);
+       int s;
 
        dev_dbg(&adev->dev, "event=%#x\n", event);
        if (event != 0x88) {
                dev_notice(&adev->dev, "Unknown ASHS event: %#x\n", event);
                return;
        }
+
+       s = asus_wireless_method(acpi_device_handle(data->adev), "HSWC",
+                                data->hswc_params->status);
+       printk("asus_wireless_notify: s=%d\n", s);
+       if (s == data->hswc_params->on)
+               data->led_state = data->hswc_params->off;
+       else
+               data->led_state = data->hswc_params->on;
+       queue_work(data->wq, &data->led_work);
+
        input_report_key(data->idev, KEY_RFKILL, 1);
        input_sync(data->idev);
        input_report_key(data->idev, KEY_RFKILL, 0);

Info: s = 4, when the LED is on, s = 5, when it's off.
I'm sure this is not the way it should be done, but maybe it helps to find a solution by one of the kernel-developers.

Cheers Wolfram

(In reply to Wolfram Köhn from comment #17)
> I did the following change, and got the led working on my notebook:
> 
> diff --git a/drivers/platform/x86/asus-wireless.c
> b/drivers/platform/x86/asus-wireless.c
> index d4aeac3477f5..8137a6ac3334 100644
> --- a/drivers/platform/x86/asus-wireless.c
> +++ b/drivers/platform/x86/asus-wireless.c
> @@ -111,12 +111,23 @@ static void led_state_set(struct led_classdev *led,
> enum led_brightness value)
>  static void asus_wireless_notify(struct acpi_device *adev, u32 event)
>  {
>         struct asus_wireless_data *data = acpi_driver_data(adev);
> +       int s;
>  
>         dev_dbg(&adev->dev, "event=%#x\n", event);
>         if (event != 0x88) {
>                 dev_notice(&adev->dev, "Unknown ASHS event: %#x\n", event);
>                 return;
>         }
> +
> +       s = asus_wireless_method(acpi_device_handle(data->adev), "HSWC",
> +                                data->hswc_params->status);
> +       printk("asus_wireless_notify: s=%d\n", s);
> +       if (s == data->hswc_params->on)
> +               data->led_state = data->hswc_params->off;
> +       else
> +               data->led_state = data->hswc_params->on;
> +       queue_work(data->wq, &data->led_work);
> +
>         input_report_key(data->idev, KEY_RFKILL, 1);
>         input_sync(data->idev);
>         input_report_key(data->idev, KEY_RFKILL, 0);
> 
> Info: s = 4, when the LED is on, s = 5, when it's off.
> I'm sure this is not the way it should be done, but maybe it helps to find a
> solution by one of the kernel-developers.
> 
> Cheers Wolfram

Thank's Wolfram,

I just tested your patch, it work's on my UX31A notebook.
Sadly, on my other UX305FA notebook, the event reported is always s=4
when pressing the airplane mode switch, so after the first pressing
the airplane led is always on. Interestingly, after a suspend resume the led
is off again. The event s=5 is never reported on this notebook for now.

Thank you again for your patch
Tasev

Interesting, it seems you can't really trust `OWGS` on some laptop models, on my laptop the implementation reads from a different port than it writes to and the value is always zero.
By using `acpi_call` directly I'm now able to query the status of the LED using
\RGPL 0x16 1
instead of
\RGPL 0x0F 1
as implemented in the DSDT.
I think the problem is easily solved by keeping track of the LED status in kernel-space w/o querying the hardware.

Hi 

I tested the patches from João Paulo Rechi Vita:
https://github.com/endlessm/linux/commit/6993ae16f3f98224cfd3fcfc9022a0a0a615dcd7
https://github.com/endlessm/linux/commit/2e50cb722dd52536b4bdb3eeacb91aad3f89d704

The airplane mode led is working on my 3 notebook UX31A, UX305FA and UX330.

Thank you João Paulo.

Hi Tasev
these patches where created more than two years ago, but still are not included in the current kernel (4.16.0-rc7+). Do you know the reason ?

Wolfram

It's working on my X556UQK notebook too !
But will it be in the final Kernel ?

Wolfram

(In reply to Wolfram Köhn from comment #21)
> Hi Tasev
> these patches where created more than two years ago, but still are not
> included in the current kernel (4.16.0-rc7+). Do you know the reason ?
> 
> Wolfram

Hi Wolfram,

Here is a link on linux-wireless: https://patchwork.kernel.org/patch/8993011/

The patches were rejected for inclusion in the kernel rfkill subsystem.

Tasev

Does that mean, that this good working solution will never come ?

Wolfram

Sadly having the decision to drive the LED when all radios are OFF in the kernel has been rejected upstream, as pointed in Comment 23. The solution moving forward will be to have something from userspace keep track of the airplane-mode status (gnome-settings-daemon currently does) and drive the LED using the /sys API.

Darren feel free to close this one.

Is, or will there be a solution for KDE too ?

Wolfram

Hi,

The bug was fixed for me in the recent kernels (I don't remember if it was
in the 4.19 or 4.18 kernel). So i close this bug repport.

Tasev