linux-kernel - Re: [PATCH] platform/x86/intel/hid: Add HP Dragonfly G2 to DMI quirks

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4b7da537-8ec3-95e2-4053-871c56e980ea@redhat.com>
Date:   Fri, 14 Jul 2023 19:00:13 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Maxim Mikityanskiy <maxtram95@...il.com>,
        Alex Hung <alexhung@...il.com>,
        Mark Gross <markgross@...nel.org>
Cc:     platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        Richard Hughes <hughsient@...il.com>,
        Jorge Lopez <jorge.lopez2@...com>
Subject: Re: [PATCH] platform/x86/intel/hid: Add HP Dragonfly G2 to DMI quirks

Hi Maxim,

On 7/12/23 19:50, Maxim Mikityanskiy wrote:
> SW_TABLET_MODE reports are broken on BIOS versions newer than 1.9.1 on
> HP Elite Dragonfly G2. Analysis of SSDT9 shows that the BTNL method has
> to be called to start getting 0xcc and 0xcd events. Apparently, the
> button_array_present method used to return true on BIOS 1.9.1 and older,
> but it returns false on newer BIOSes due to HEBC returning 0x000033f3
> (bits 0x60000 and 0x20000 are not set).
> 
> Add this laptop to button_array_table to force the BTNL call, and also
> add it to dmi_vgbs_allow_list to read the initial state and sync VBDS
> with VBPS, because this laptop has a reliable VGBS method.
> 
> Tested with BIOS 1.13.1.
> 
> Signed-off-by: Maxim Mikityanskiy <maxtram95@...il.com>

Thank you for figuring this out and thank you for the patch.

WRT the need to call BTNL, I expect that if one laptop needs this likely more models will need it and I expect / hope that this will not cause any issues when called everywhere.

So I think it would be better to instead of adding this model to the button_array_table[] it would be better to just always call BTNL (I suspect this is also what Windows does).

Can you give the attached path to always call BTNL a try ?

As for adding the model to dmi_vgbs_allow_list[] on many models it seems that the EC will send a 0xcc / 0xcd event at boot (now that I think about it I guess this may be in response to the BTNL call) and then on that event the SW_TABLET_STATE evdev gets registered and the first event also syncs the state.

Can you check if just using the always call BTNL patch, without the quirk perhaps already makes the SW_TABLET_STATE evdev show up (including the correct state) ?

If no event is send during boot, the n I'm fine with adding the model to the dmi_vgbs_allow_list[], but perhaps this is not necessary?

Regards,

Hans

> ---
>  drivers/platform/x86/intel/hid.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel/hid.c b/drivers/platform/x86/intel/hid.c
> index 5632bd3c534a..5c78b476ed1e 100644
> --- a/drivers/platform/x86/intel/hid.c
> +++ b/drivers/platform/x86/intel/hid.c
> @@ -128,6 +128,13 @@ static const struct dmi_system_id button_array_table[] = {
>  			DMI_MATCH(DMI_PRODUCT_NAME, "Surface Go 3"),
>  		},
>  	},
> +	{
> +		.ident = "HP Elite Dragonfly G2",
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite Dragonfly G2 Notebook PC"),
> +		},
> +	},
>  	{ }
>  };
>  
> @@ -150,6 +157,12 @@ static const struct dmi_system_id dmi_vgbs_allow_list[] = {
>  			DMI_MATCH(DMI_PRODUCT_NAME, "Surface Go"),
>  		},
>  	},
> +	{
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite Dragonfly G2 Notebook PC"),
> +		},
> +	},
>  	{ }
>  };
>  

View attachment "0001-platform-x86-intel-hid-Always-call-BTNL-ACPI-method.patch" of type "text/x-patch" (2495 bytes)