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@xxxxxxxxxx>
> ---
> 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@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
