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

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

On 25/11/2015 04:53, Andrei Borzenkov wrote:
> 24.11.2015 01:33, Gabriele Mazzotta пишет:
>
>> I'll try to write a summary that should explain why dell-rbtn exists
>> and what are the current problems.
>>
>> There are several mechanisms to control radio devices, so let's
>> consider different categories/cases.
>>
>> A) The function keys of new Dell laptops do nothing on their own, but
>> when pressed, the BIOS sends a notification to an ACPI device
>> (DELLABCE/DELRBTN). One of the tasks of dell-rbtn is to catch those
>> notifications and send an input event to userspace. Without dell-rbtn,
>> the function keys of these laptops wouldn't work.
>>
>> B) There are then some other laptops which support two different
>> mechanisms to control radio devices: the one here above (A) and
>> "the old one", i.e. the BIOS does everything. (These are probably
>> laptops that were released during the transition Windows 7 -> 8). These
>> laptops can switch between the two modes through an ACPI method call.
>> What we do with dell-rbtn is to make them behave like (A) since we
>> can't tell apart laptops of (A) and (B) and we need to know how each
>> laptop behaves. The function key of these laptops work perfectly
>> without dell-rbtn.
>>
>> C) There are then some other laptops for which it's required to use an
>> i8042 filter to detect keypresses and do some SMI calls to toggle
>> the state of radio devices. This filter is created by dell-laptop and
>> has been there since a long time.
>>
>> D) This category is something in between (C) and (A) and exists only
>> because of dell-rbtn. Some of the laptops of category (C) also have a
>> DELLABCE/DELLRBTN device.
>
> I'm pretty confident that my Dell Latitude falls into this category.
> What happens here apparently is
>
> - user presses hotkey on keyboard
> - hotkey is handled by BIOS to toggle radio
> - BIOS sends notification to OS via ACPI that something changed and OS
> must query current radio state

So is the i8042 filter doing anything? What happens if you remove your
laptop from the whitelist of dell-laptop (see dell_setup_rfkill())?
Is dell-rbtn handling your function key presses correctly in this case?

> Adding debug print do dell-laptop and dell-rbtn
>
> [43345.599909] dell-laptop: got keyboard event
> [43345.704558] dell-rbtn DELLABCE:00: Received event (0x80)
>
> So ACPI event comes rather later after key press.

According to some Windows documentation, the ACPI event must come after
the function key is released.

> This makes those notifications at wake up not spurious at all - they are
> actually pretty logical, and serve to make OS ascertain current status
> of radio kill switch. But I am pretty much confident that those events
> do NOT mean to be used as request to toggle kill switch state.

They are spurious in my case.

>
>> When dell-rbtn is loaded, the i8042 filter is
>> removed and dell-rbtn starts listening for ACPI notification. We do
>> this instead because the i8042 filter doesn't work properly on some
>> laptops.
>>
>>
>
> And here is the actual bug. dell-rbtn handles category D as if it were
> category A. For category D it should *not* send input event, but rather
> hook and notify dell-laptop to query current kill switch state (because
> at least on my system there is no way to do it via ACPI RBTN).
>
> So the actual problem is to differentiate between categories A and D. Is
> it possible to do based on ACPI name (DELRBTN vs DELLABCE) or may be on
> return value of CRBT? If not we really need black/white list here based
> on DMI or something.
>
> And BTW these input events are consumed by kernel in filter installed by
> net/rfkill/input.c, so they are not really user space.
>
>> 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.
>
> If dell-rbtn did the right thing for my laptop, those notifications were
> harmless.
>
>> 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.
>>
>
> Are you sure the laptops in bugzilla are actually of type A and not of
> type D? That would match what I observe here.

I have the same laptop, which is of type B. Without dell-rbtn the BIOS
handles radios, with dell-rbtn it simply sends ACPI notifications.

>>
>> [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
>>
>