On Wed, Mar 28, 2018 at 1:06 AM, Dun Hum <bitter.taste@xxxxxxx> wrote: >> Sent: Monday, March 26, 2018 at 5:34 AM >> From: "João Paulo Rechi Vita" <jprvita@xxxxxxxxx> >> To: "Darren Hart" <dvhart@xxxxxxxxxxxxx> >> Cc: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx>, "Corentin Chary" <corentin.chary@xxxxxxxxx>, acpi4asus-user <acpi4asus-user@xxxxxxxxxxxxxxxxxxxxx>, tasev.stefanoska@xxxxxxxxx, "Platform Driver" <platform-driver-x86@xxxxxxxxxxxxxxx>, "Dun Hum" <bitter.taste@xxxxxxx> >> Subject: Re: Regression: airplane mode led is not working anymore on Asus UX31A , UX305FA and UX330 4.11-rc2 kernel >> >> >> The patch series referred here intended to avoid having asus-wmi >> driving the LED as a side-effect of saving the WLAN state, and letting >> asus-wireless drive it. Without this patch the LED was reflecting the >> WLAN state (ON when WLAN was enabled, OFF when WLAN was disabled) >> instead of the airplane-mode state, which is wrong since the LED is >> labeled with an airplane icon (and also comparing with the behavior on >> Windows). Thus, this is not a regression. >> > > On my laptop there's no airplane and windows did not treat the led as such > (afair) even though the ATK4001 device is present. What is this laptop model? Can you please provide a picture of the LED label, and confirm what is the behavior on Windows with the "Asus Wireless Radio Control" driver installed? For all the recent Asus machines we worked with at Endless, the behavior expected from the QA team at Asus is to have the LED ON when the radios on the system are OFF, indicating airplane mode. I'm not completely discarding the possibility that you may have a machine where the vendor decided to implement a different behavior, but I think is very unlikely. If that is the case, please provide a video clearly showing this behavior when using the vendor drivers on Windows. In addition, as explained before, there is nothing driving the LED at the moment, as the patch which intended to drive it was rejected, and nothing in userspace implements it. > I'd also say it's a regression because the patch: > > 1) The led doesn't work as expected Already commented above. > 2) The driver in the 4.9 series (used by Debian) uses 4/5 to turn off/on > the led while this version of the ATK uses 0/1 instead (this has been > fixed in a later version but was not backported) I'm not sure this is the kind of fix which would be backported to a stable series, but I may be wrong here. > 3) The driver tries to free an invalid pointer when unloaded (see > https://bugzilla.kernel.org/show_bug.cgi?id=196467 and > https://bugzilla.kernel.org/show_bug.cgi?id=196097) > These are different problems from what is being discussed here (LED status), I'll look at the bug reports. > Moreover, after some exploration using acpi_call, I've discovered that > calling HSWC(2) (or OWGL) always returns zero no matter what the > status of the LED is. Feel free to open a separate bug report for this problem, and make sure to include a kernel log showing the problem with dynamic_debug enabled for asus-wireless, together with full model info and the DSDT. Still, it sounds like a hardware bug, in which case there is not much we can do about it. -- João Paulo Rechi Vita http://about.me/jprvita
