Bug 195563 - airplane mode led is not working anymore on Asus UX31A , UX305FA and UX330 4.11-rc2 kernel
Summary: airplane mode led is not working anymore on Asus UX31A , UX305FA and UX330 4...
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform_x86 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_platform_x86@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-24 13:42 UTC by Tasev Nikola
Modified: 2019-02-11 14:54 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.11-rc2 4.10.10
Tree: Mainline
Regression: Yes


Attachments
dmesg kernel 4.10.10 Asus UX330 after pressing fn+f2 to switch on/off the airplane mode (53.89 KB, text/plain)
2017-04-24 13:42 UTC, Tasev Nikola
Details
DSDT from Asus UX330 (1.21 MB, text/x-csrc)
2017-04-24 13:45 UTC, Tasev Nikola
Details
demidecode from Asus UX330UA (12.40 KB, text/plain)
2017-05-06 09:38 UTC, Tasev Nikola
Details
DSDT from Asus UX31A (614.94 KB, text/x-csrc)
2017-05-15 17:23 UTC, Tasev Nikola
Details
DSDT from Asus UX305FA (828.47 KB, text/x-csrc)
2017-05-15 17:24 UTC, Tasev Nikola
Details
DSDT from Asus X556UQK (1.26 MB, text/x-csrc)
2018-02-27 14:41 UTC, Wolfram Köhn
Details

Description Tasev Nikola 2017-04-24 13:42:08 UTC
Created attachment 255985 [details]
dmesg kernel 4.10.10 Asus UX330 after pressing fn+f2 to switch on/off the airplane mode

Hi,

Sorry to not reporting this sooner but I just noticed yesterday that the 
airplane mode led is not working anymore on my Asus UX31A , UX305FA and UX330 
starting from kernel 4.11-rc2.

In the stable 4.10 kernel the led is not working starting from version 4.10.10.
Probably related to the patches to asus-wmi from João Paulo Rechi Vita?

I have also only in my UX330 one pcie related error in dmesg every time i press the fn+f2 key's to switch on/off the airplane mode with the not working kernel's.The erroris not present with the working kernels.

[   62.888355] pcieport 0000:00:1c.6: AER: Corrected error received: id=00e6
[   62.888363] pcieport 0000:00:1c.6: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e6(Receiver ID)
[   62.888367] pcieport 0000:00:1c.6:   device [8086:9d16] error status/mask=00000001/00002000
[   62.888369] pcieport 0000:00:1c.6:    [ 0] Receiver Error         (First)

Full dmesg from kernel 4.10.10 is attached, also is the dsdt from the UX330.

Tasev
Comment 1 Tasev Nikola 2017-04-24 13:45:10 UTC
Created attachment 255987 [details]
DSDT from Asus UX330
Comment 2 Darren Hart 2017-05-05 18:29:27 UTC
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`?
Comment 3 Tasev Nikola 2017-05-06 09:37:14 UTC
(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.
Comment 4 Tasev Nikola 2017-05-06 09:38:48 UTC
Created attachment 256237 [details]
demidecode from Asus UX330UA
Comment 5 Tasev Nikola 2017-05-15 17:22:35 UTC
(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)
                    }
Comment 6 Tasev Nikola 2017-05-15 17:23:35 UTC
Created attachment 256535 [details]
DSDT from Asus UX31A
Comment 7 Tasev Nikola 2017-05-15 17:24:23 UTC
Created attachment 256537 [details]
DSDT from Asus UX305FA
Comment 8 Tasev Nikola 2017-06-07 15:51:00 UTC
Hi

The bug is still present in the 4.12-rc4 kernel
Comment 9 Wolfram Köhn 2018-02-14 10:40:27 UTC
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
Comment 10 Tasev Nikola 2018-02-15 14:22:40 UTC
Hi
The bug is still present in the 4.16-rc1 kernel.
Comment 11 Wolfram Köhn 2018-02-27 14:41:27 UTC
Created attachment 274475 [details]
DSDT from Asus X556UQK

DSDT from Asus X556UQK
Comment 12 Wolfram Köhn 2018-02-27 14:43:16 UTC
The bug is still present in the 4.16-rc3 kernel.
Comment 13 Wolfram Köhn 2018-02-28 13:25:55 UTC
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 ?
Comment 14 Wolfram Köhn 2018-03-16 09:25:51 UTC
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
Comment 15 Dr.Pepper 2018-03-24 15:37:25 UTC
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.
Comment 16 Dr.Pepper 2018-03-24 16:55:32 UTC
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.
Comment 17 Wolfram Köhn 2018-03-29 11:32:42 UTC
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
Comment 18 Tasev Nikola 2018-03-30 08:42:02 UTC
(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
Comment 19 Dr.Pepper 2018-03-30 14:16:07 UTC
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.
Comment 20 Tasev Nikola 2018-03-30 18:37:48 UTC
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.
Comment 21 Wolfram Köhn 2018-03-31 11:46:41 UTC
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
Comment 22 Wolfram Köhn 2018-03-31 12:43:38 UTC
It's working on my X556UQK notebook too !
But will it be in the final Kernel ?

Wolfram
Comment 23 Tasev Nikola 2018-03-31 18:31:04 UTC
(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
Comment 24 Wolfram Köhn 2018-04-01 11:10:33 UTC
Does that mean, that this good working solution will never come ?

Wolfram
Comment 25 João Paulo Rechi Vita 2018-04-07 00:55:53 UTC
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.
Comment 26 Wolfram Köhn 2018-04-10 11:16:30 UTC
Is, or will there be a solution for KDE too ?

Wolfram
Comment 27 Tasev Nikola 2019-02-11 14:54:41 UTC
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

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