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

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

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).

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