| Message ID | 17238db9f090e8b2c80756ccd4bcd8f4f1e3bfab.1455553470.git.luto@kernel.org (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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 }, > }; >
On 02/17/2016 05:16 AM, Pali Rohár wrote: > 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)? DELLABC6 is a custom interface that was created solely to have airplane mode support for Windows 7. For Windows 10 the proper interface is to use that which is handled by intel-hid. A OEM airplane mode driver is not used. Since the kernel doesn't identify as Windows 7 it would be incorrect to do attempt to use that interface. >> + * 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 }, >> }; >> -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 17 February 2016 07:07:28 Mario Limonciello wrote: > > > On 02/17/2016 05:16 AM, Pali Rohár wrote: > > 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)? > DELLABC6 is a custom interface that was created solely to have airplane > mode support for Windows 7. > For Windows 10 the proper interface is to use that which is handled by > intel-hid. A OEM airplane mode driver is not used. > > Since the kernel doesn't identify as Windows 7 it would be incorrect to > do attempt to use that interface. Ok, I understand. But what user can is to tell linux kernel to identify as Windows 7. And I would like to know reason for that inconsistent behaviour. It is because of bug in NetworkManager or because of some hidden bug in dell-rbnt.c or in rfkill kernel subsystem? If it is in kernel there is really big change that it can occur also on other machines which uses dell-rbtn and so we should fix it. Andy, can you look at it and try identify where is the problem? > >> + * 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 }, > >> }; > >> >
On Feb 23, 2016 4:01 AM, "Pali Rohár" <pali.rohar@gmail.com> wrote: > > On Wednesday 17 February 2016 07:07:28 Mario Limonciello wrote: > > > > > > On 02/17/2016 05:16 AM, Pali Rohár wrote: > > > 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)? > > DELLABC6 is a custom interface that was created solely to have airplane > > mode support for Windows 7. > > For Windows 10 the proper interface is to use that which is handled by > > intel-hid. A OEM airplane mode driver is not used. > > > > Since the kernel doesn't identify as Windows 7 it would be incorrect to > > do attempt to use that interface. > > Ok, I understand. But what user can is to tell linux kernel to identify > as Windows 7. > > And I would like to know reason for that inconsistent behaviour. It is > because of bug in NetworkManager or because of some hidden bug in > dell-rbnt.c or in rfkill kernel subsystem? If it is in kernel there is > really big change that it can occur also on other machines which uses > dell-rbtn and so we should fix it. > > Andy, can you look at it and try identify where is the problem? I think it's straightforward. If we identify as Windows 7 and enable this driver then, when we press the wireless button, dell-rbtn switches its state *and* NetworkManager gets KEY_RFKILL from intel-hid and changes its state. Then you can tell NetworkManager to turn wifi on using the menu, at which point dell-rbtn is off but NM's software state is on. Then you press the button again, turning on dell-rbtn but turning NM off again. The result is that the last button press direct work as expected. I haven't verified that this is actually what happens, but it's certainly the case that a button that triggers a state toggle should only change the state by *one* mechanism. Presumably this works on Windows 7 because either there is no equivalent of intel-hid or because the DSDT turns it off -- I haven't checked which is the case. --Andy -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/23/2016 11:35 AM, Andy Lutomirski wrote: > > Presumably this works on Windows 7 because either there is no > equivalent of intel-hid or because the DSDT turns it off -- I haven't > checked which is the case. That's correct, the DSDT doesn't offer the ACPI device corresponding to intel-hid for Linux in Win7 otherwise it would be a "yellow bang" in device manager that can't be resolved. -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 23 February 2016 09:35:47 Andy Lutomirski wrote: > On Feb 23, 2016 4:01 AM, "Pali Rohár" <pali.rohar@gmail.com> wrote: > > > > On Wednesday 17 February 2016 07:07:28 Mario Limonciello wrote: > > > > > > > > > On 02/17/2016 05:16 AM, Pali Rohár wrote: > > > > 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)? > > > DELLABC6 is a custom interface that was created solely to have airplane > > > mode support for Windows 7. > > > For Windows 10 the proper interface is to use that which is handled by > > > intel-hid. A OEM airplane mode driver is not used. > > > > > > Since the kernel doesn't identify as Windows 7 it would be incorrect to > > > do attempt to use that interface. > > > > Ok, I understand. But what user can is to tell linux kernel to identify > > as Windows 7. > > > > And I would like to know reason for that inconsistent behaviour. It is > > because of bug in NetworkManager or because of some hidden bug in > > dell-rbnt.c or in rfkill kernel subsystem? If it is in kernel there is > > really big change that it can occur also on other machines which uses > > dell-rbtn and so we should fix it. > > > > Andy, can you look at it and try identify where is the problem? > > I think it's straightforward. If we identify as Windows 7 and enable > this driver then, when we press the wireless button, dell-rbtn > switches its state *and* NetworkManager gets KEY_RFKILL from intel-hid > and changes its state. Then you can tell NetworkManager to turn wifi > on using the menu, at which point dell-rbtn is off but NM's software > state is on. Then you press the button again, turning on dell-rbtn > but turning NM off again. The result is that the last button press > direct work as expected. > > I haven't verified that this is actually what happens, but it's > certainly the case that a button that triggers a state toggle should > only change the state by *one* mechanism. > > Presumably this works on Windows 7 because either there is no > equivalent of intel-hid or because the DSDT turns it off -- I haven't > checked which is the case. > > --Andy Understood, this is just big API mess in Dell APCI/EC/firmware and also our kernel implementation in (dell-(laptop|wmi|rbtn)|intel-hid) drivers is not ideal and clean... Darren, add my Acked-by also for this patch (if you already have not done it).
On Thu, Feb 25, 2016 at 11:45:28AM +0100, Pali Rohár wrote: > On Tuesday 23 February 2016 09:35:47 Andy Lutomirski wrote: > > On Feb 23, 2016 4:01 AM, "Pali Rohár" <pali.rohar@gmail.com> wrote: > > > > > > On Wednesday 17 February 2016 07:07:28 Mario Limonciello wrote: > > > > > > > > > > > > On 02/17/2016 05:16 AM, Pali Rohár wrote: > > > > > 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(+) > > > > >> > > > Andy, can you look at it and try identify where is the problem? > > > > I think it's straightforward. If we identify as Windows 7 and enable > > this driver then, when we press the wireless button, dell-rbtn > > switches its state *and* NetworkManager gets KEY_RFKILL from intel-hid > > and changes its state. Then you can tell NetworkManager to turn wifi > > on using the menu, at which point dell-rbtn is off but NM's software > > state is on. Then you press the button again, turning on dell-rbtn > > but turning NM off again. The result is that the last button press > > direct work as expected. > > > > I haven't verified that this is actually what happens, but it's > > certainly the case that a button that triggers a state toggle should > > only change the state by *one* mechanism. > > > > Presumably this works on Windows 7 because either there is no > > equivalent of intel-hid or because the DSDT turns it off -- I haven't > > checked which is the case. > > > > --Andy > > Understood, this is just big API mess in Dell APCI/EC/firmware and also > our kernel implementation in (dell-(laptop|wmi|rbtn)|intel-hid) drivers > is not ideal and clean... > > Darren, add my Acked-by also for this patch (if you already have not > done it). This is done and in next already. > > -- > Pali Rohár > pali.rohar@gmail.com >
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 }, };
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(+)