Re: [PATCH v5 5/5] dell-rbtn: Add a comment about the XPS 13 9350

["Pali Rohár" <pali.rohar@gmail.com>]

On Monday 15 February 2016 08:32:37 Andy Lutomirski wrote:
> On the XPS 13 9350, the dell-rbtn mechanism has a new device id, and
> the DSDT turns it off if a new enough _OSI is supported.  Add a
> comment about why we don't bother supporting it.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  drivers/platform/x86/dell-rbtn.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
> index cd410e392550..b51a2008d782 100644
> --- a/drivers/platform/x86/dell-rbtn.c
> +++ b/drivers/platform/x86/dell-rbtn.c
> @@ -217,6 +217,21 @@ static void rbtn_notify(struct acpi_device *device, u32 event);
>  static const struct acpi_device_id rbtn_ids[] = {
>  	{ "DELRBTN", 0 },
>  	{ "DELLABCE", 0 },
> +
> +	/*
> +	 * This driver can also handle the "DELLABC6" device that
> +	 * appears on the XPS 13 9350, but that device is disabled
> +	 * by the DSDT unless booted with acpi_osi="!Windows 2012"
> +	 * acpi_osi="!Windows 2013".  Even if we boot that and bind
> +	 * the driver, we seem to have inconsistent behavior in
> +	 * which NetworkManager can get out of sync with the rfkill
> +	 * state.

Do you know reason for such behaviour? It is because event is send
duplicated (by dell-rbtn and also by intel-hid)?

> +	 * On the XPS 13 9350 and similar laptops, we're not supposed to
> +	 * use DELLABC6 at all.  Instead, we handle the rfkill button
> +	 * via the intel-hid driver.
> +	 */
> +
>  	{ "", 0 },
>  };
>  

-- 
Pali Rohár
pali.rohar@gmail.com