From 4d340c6b9cc7e6e5f6ad4fc27e837863015cdf5b Mon Sep 17 00:00:00 2001 From: Andy Lutomirski Date: Mon, 15 Feb 2016 08:32:37 -0800 Subject: dell-rbtn: Add a comment about the XPS 13 9350 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Acked-by: Pali Rohár Signed-off-by: Darren Hart --- drivers/platform/x86/dell-rbtn.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'drivers/platform') 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. + * + * 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 }, }; -- cgit v1.2.1