Re: Regression with dell-rbtn: radio killed on resume after suspend to RAM

[Gabriele Mazzotta <gabriele.mzt@gmail.com>]

On 24/11/2015 05:06, Andrei Borzenkov wrote:
> 24.11.2015 01:33, Gabriele Mazzotta пишет:
> [...snip...]
>>
>> The problem reported in [1] is that some laptops of (A) and (B) send a
>> notification on resume and some others don't. [2] should fix this
>> problem, but we need to make sure that the extra notification is always
>> caught before the resume of dell-rbtn. This seems to be what happens
>> here on my laptop, but Andrei says otherwise. So we need to figure out
>> if [2] doesn't fix the problem because it's not guaranteed that ACPI
>> notifications sent while the system is resuming are received by device
>> drivers before they are resumed (assumption that I made for the first
>> patch and that dropped with the updated one I sent in this thread) or
>> because Andrei's problem is something different.
>>
>>
>> I hope this was clear enough.
>>
>>
>> Andrei, as I wrote here above, dell-rbtn _should_ make dell-laptop
>> remove the i8042 filter.
>
> No. In dell_rbtn_notifier_register() it checks for RBTN of type SLIDER
> using rbtn_inc_count(). If no SLIDER is found it returns ENODEV and
> dell-laptop proceeds with i8042 hook.
>
> [   16.685944] dell_laptop: Using i8042 filter function for receiving
> events
>
> But that does *not* stop dell-rbtn from actually running and sending
> input events:

I think I see the problem now. Your case (RBTN_TOGGLE + 
Latitude/Precision) wasn't taken into account. I think my laptop and 
yours behave in the same way, but since mine is an XPS, dell-laptop 
doesn't create the rfkill + filter for it. dell-laptop does this only
for Latitude and Precision laptops.

> /*
>   * acpi driver functions
>   */
>
> static int rbtn_add(struct acpi_device *device)
> {
> ...
>          case RBTN_TOGGLE:
>                  ret = rbtn_input_init(rbtn_data);
>                  break;
>
> So as I said, we now have both of them handling the same key press.
>
> Also using dell-laptop (3.13 kernel) and dell-laptop + dell-rbtn (4.2
> kernel with your patch to ignore events during suspend) I see different
> reaction to key press:
>
> 3.13
>
> 0: dell-wifi: Wireless LAN
>      Soft blocked: no
>      Hard blocked: no
> 1: dell-bluetooth: Bluetooth
>      Soft blocked: no
>      Hard blocked: no
> 2: phy0: Wireless LAN
>      Soft blocked: no
>      Hard blocked: no
> 6: hci0: Bluetooth
>      Soft blocked: no
>      Hard blocked: no
>
> Press rfkill button
>
> 0: dell-wifi: Wireless LAN
>      Soft blocked: no
>      Hard blocked: yes
> 1: dell-bluetooth: Bluetooth
>      Soft blocked: no
>      Hard blocked: yes
> 2: phy0: Wireless LAN
>      Soft blocked: no
>      Hard blocked: yes
>
> 4.2
>
> 0: dell-wifi: Wireless LAN
>      Soft blocked: no
>      Hard blocked: no
> 1: dell-bluetooth: Bluetooth
>      Soft blocked: no
>      Hard blocked: no
> 2: hci0: Bluetooth
>      Soft blocked: no
>      Hard blocked: no
> 3: phy0: Wireless LAN
>      Soft blocked: no
>      Hard blocked: no
>
> Press rfkill button
>
> 0: dell-wifi: Wireless LAN
>      Soft blocked: yes
>      Hard blocked: no
> 1: dell-bluetooth: Bluetooth
>      Soft blocked: yes
>      Hard blocked: no
> 2: hci0: Bluetooth
>      Soft blocked: yes
>      Hard blocked: no
> 3: phy0: Wireless LAN
>      Soft blocked: yes
>      Hard blocked: yes
>
> I am not sure whether keyboard key should be treated as hard or soft
> (i.e. I do not know how to verify that radio is switched off without OS
> running), but I still expect the same behavior in both cases.

Unfortunately this is expected. Looking at your DSDT it seems that the
function key of your laptop is not intended to hard block radio devices.

Also, I can see that a notification is sent on resume.

>> Could you also provide your acpidump so that
>> I can see it?
>>
>
> Attached (I thought about adding to bugzilla, but as we are not sure
> whether it is the same bug, I send it here).
>
> I have old Dell XPS M1303 with both slider and button type of rfkill,
> I'll try to see what happens there.

I think the BIOS is sending a notification on resume also on your
laptop, but I could be wrong. The followings should be the ACPI method
calls that happen on resume:
_WAK -> RWAK -> EV2 -> \_SB.RBTN.NRBT (this one notifies RBTN)

So you have two problems: the extra notification + i8042 filter.

> P.S. it seems that RBTN is exposed if _OSI claims sufficiently recent
> Windows is present; I tried booting with acpi_osi=! acpi_osi=Linux and
> got no RBTN device at all. I wonder how Windows handles it.

Windows 8 has changed the way radio function keys work. They are now
stateless buttons that inform the OS when they are pressed. It's up to
the OS handle the state of radio devices.

This is the reason why you see a different output using the rfkill +
dell-rbtn. We are handling radio devices as Windows does, mostly
because it's the only way to handle the function key of some laptops.

Your laptop should actually be one of those, but since it's a Latitude,
dell-laptop gets in the way. I also have issues when I load dell-laptop
(RBTN_TOGGLE here) with the force_rfkill param (mine is an XPS).


Pali, what should we do for the case Latitude/Precision + RBTN_TOGGLE?

>>
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=106031
>> [2]
>> http://lkml.kernel.org/r/1448115375-7315-1-git-send-email-gabriele.mzt@gmail.com
>>
>>
>