linux-kernel - RE: Keyboard regression by intel-vbtn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR19MB2636919AD0E9FD06F05AC8A8FA330@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Wed, 30 Sep 2020 15:12:00 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     Hans de Goede <hdegoede@...hat.com>,
        Barnabás Pőcze <pobrn@...tonmail.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:     "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Takashi Iwai <tiwai@...e.de>
Subject: RE: Keyboard regression by intel-vbtn

> -----Original Message-----
> From: Hans de Goede <hdegoede@...hat.com>
> Sent: Wednesday, September 30, 2020 8:28
> To: Limonciello, Mario; Barnabás Pőcze; Andy Shevchenko
> Cc: platform-driver-x86@...r.kernel.org; linux-kernel@...r.kernel.org; Takashi
> Iwai
> Subject: Re: Keyboard regression by intel-vbtn
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> On 9/29/20 10:47 PM, Limonciello, Mario wrote:
> >>
> >> I requested on the Ubuntu bug for someone to provide these.
> >>
> >
> > Joe Barnett was kind enough to share two ACPI dumps to compare.
> > Not affected:
> >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394/+attachment/54153
> 18/+files/1.2.0.acpidump
> >
> > Affected:
> >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394/+attachment/54154
> 05/+files/1.13.0.acpidump
> 
> Thank you, I took a look at these (before completing my allow-list fix),
> but there is not really much which stands out. The only related thing which
> stands out is that the 1.13.0 dsdt.dsl has this new bit:
> 
> 
>                              Case (0x08)
>                              {
>                                  Return (^^PCI0.LPCB.H_EC.VGBI.VGBS ())
>                              }
> 
> Inside the _DSM of the HIDD / INT33D5 device.
> 
>              Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
>              {
>                  If ((Arg0 == ToUUID ("eeec56b3-4442-408f-a792-
> 4edd4d758054")))
> 
> 
> What is interesting here is that the PCI0.LPCB.H_EC.VGBI.VGBS object/method
> does not actually exist the correct path is:
> 
> ^^PCI0.LPCB.ECDV.VGBI.VGBS
> 
> So this does suggest that something around the VGBS handling changed
> (and since it points to a non existing ACPI object, possibly broke)
> in the newer BIOS version. But what exactly is going on on this XPS 2-in-1
> cannot really be derived from the acpidumps.
> 
> Regards,
> 
> Hans

Looking through some publicly found content I think I might have figured out what
bight be the missing link.

https://software.intel.com/sites/default/files/detecting-slate-clamshell-mode-and-screen-orientation-in-convertible-pc-1.pdf

You can see that the device with CID PNP0C60 is supposed to indicate the presence
of a convertible hinge.  We don't currently have anything that matches that _CID or _HID
in intel-vbtn.

In the DSDT dump you can see that the status method for the INT33D3 device returns
0x0F on 2-in-1.s

        Device (CIND)
        {
            Name (_HID, "INT33D3" /* Intel GPIO Buttons */)  // _HID: Hardware ID
            Name (_CID, "PNP0C60" /* Display Sensor Device */)  // _CID: Compatible ID
            Method (_STA, 0, Serialized)  // _STA: Status
            {
                If ((OSYS >= 0x07DC))
                {
                    Return (0x0F)
                }

                Return (Zero)
            }
        }

On a non 2-in-1 device I don't see this present.  So I think we should have intel-vbtn
look for that INT33D3/PNP0C60 device to decide whether to offer the switch.

Similarly as mentioned in that document I think that we should not be showing the
docking switch only when INT33D4/PNP0C70 is present and returns 0xF.