On Tuesday 23 February 2016 09:35:47 Andy Lutomirski wrote:
> On Feb 23, 2016 4:01 AM, "Pali Rohár" <pali.rohar@xxxxxxxxx> 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@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)?
> > > 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@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
