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: <1A14B7E7-4AF9-49A7-ABC9-BEDDC57C4DD4@gmail.com>
Date: Wed, 25 Dec 2024 23:17:36 -0800
From: "Derek J. Clark" <derekjohn.clark@...il.com>
To: Armin Wolf <W_Armin@....de>, "Cody T.-H. Chiu" <codyit@...il.com>,
 Hans de Goede <hdegoede@...hat.com>, ike.pan@...onical.com
CC: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Jonathan Corbet <corbet@....net>, Luke Jones <luke@...nes.dev>,
 Xino Ni <nijs1@...ovo.com>, Zhixin Zhang <zhangzx36@...ovo.com>,
 Mia Shao <shaohz1@...ovo.com>, Mark Pearson <mpearson-lenovo@...ebb.ca>,
 "Pierre-Loup A . Griffais" <pgriffais@...vesoftware.com>,
 platform-driver-x86@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] platform/x86: Add lenovo-legion-wmi drivers



On December 25, 2024 1:11:32 PM PST, Armin Wolf <W_Armin@....de> wrote:
>Am 25.12.24 um 09:34 schrieb Derek J. Clark:
>
>> 
>> On December 24, 2024 9:25:19 PM PST, "Cody T.-H. Chiu" <codyit@...il.com> wrote:
>>> On 12/17/2024 17:06, Derek J. Clark wrote:
>>>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>>>> ...
>>>> +config LEGION_OTHER_WMI
>>>> +	tristate "Lenovo Legion Other Method WMI Driver"
>>>> +	depends on LEGION_GAMEZONE_WMI
>>>> +	depends on LEGION_DATA_01_WMI
>>>> +	select FW_ATTR_CLASS
>>>> +	help
>>>> +	  Say Y here if you have a WMI aware Lenovo Legion device and would
>>> like to use the
>>>> +	  firmware_attributes API to control various tunable settings
>>> typically exposed by
>>>> +	  Lenovo software in Windows.
>>>> +
>>>> +	  To compile this driver as a module, choose M here: the module will
>>>> +	  be called lenovo_legion_wmi_other.
>>>> +
>>>>    config IDEAPAD_LAPTOP
>>>>    	tristate "Lenovo IdeaPad Laptop Extras"
>>>>    	depends on ACPI
>>> Hi Derek,
>>> 
>>> Thank you for the initiative, love to see we'll finally get a driver developed with the help of official specs.
>>> 
>>> Perhaps it's common knowledge to the crowd here but I'd like to call out right now significant portion of the support on Legion ACPI / WMI came from ideapad-laptop which explicitly detects it:
>>> 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/ideapad-laptop.c?h=v6.13-rc4#n2108
>> 
>> Hi Cody,
>> 
>> Doing a quick search of that GUID on the Lenovo Legion WMI spec there are no matches. Perhaps someone at Lenovo can shed some light here, but the IdeaPad driver grabbing that GUID shouldn't interfere with the GUID's we're working on here.
>> 
>>> Per my observation majority of users have no idea this is the case because of the misnomer, adding another set of drivers with Legion in the name explicitly, that don't support those features would double the dissonance.
>> It appears the feature sets are quite different. This seems to enable use of special function/media keys on some (one?) Legion laptops, and it also tries to register an ACPI based platform profile. While the driver does load on my legion go, only the amd_pmf and lenovo-legion-wmi-gamezone drivers have platform profiles registered under the new class at /sys/class/platform-profile/ so that isn't a conflict. I think that the ACPI method may only work on the yoga laptops that are supported by this driver? Again, maybe one of the Lenovo reps can comment on that, but it appears to predate the Custom and Other mode WMI GUID's.
>
>Maybe we can remove the "legion" part from the driver name since this WMI device seems to be used on other machines too. Maybe you can instead use "lenovo" when naming the drivers?
>
>Thanks,
>Armin Wolf

I think you have it backwards. Per the spec only legion laptops will use the GUID's for gamezone, custom/other method, lighting, or capability data. Removing legion from the driver name would probably cause more confusion. The GUID in the IdeaPad driver is what seems out of place. I took a closer look at it and the functionality provided by the GUID he mentioned is a notify for when Fn keys are pressed and none of the other GUIDs have that flag implemented. There is a comment about it being for a legion 5 laptop but it may be the case that some IdeaPad laptops use it as well, I'll ask some of the Lenovo folks directly and see if I can get a positive answer if it is a generic Lenovo interface. IMO if we want to reduce confusion it might make more sense to move that GUID into its own driver at a later date, naming it lenovo-wmi-something without a specific product line, or if it's only used on legion laptops then calling it lenovo-legion-wmi-something might be preferred. Alternatively renaming the IdeaPad driver lenovo-laptop could work to disambiguate it. TBS i don't think it's a high priority right now. I'm going to focus on the gamezone and other method drivers for now.

Regards,
Derek

>> 
>>> I wonder if reconciling this is in your planned scope? If not IMO at least this should be called out in documentation / Kconfig.
>> Reconciliation wouldn't be in-line with the WMI driver requirements outlined in the kernel docs as each unique GUID needs to have its own driver in the current spec. It is possible we might need to add a quirk table in the future if we want to add function keys support for the Custom Method or Other Method function keys in the future. Since the Go has no keyboard I can't confirm if the IdeaPad driver is functional on more legion laptops, but considering the DMI quirks that are used in conjunction I would assume support needs to be added explicitly.
>> 
>> If someone wants to add documentation on the IdeaPad driver and what it provides that would be good. I'm not familiar enough with it to really do it myself.
>
>As long as both drivers use different GUIDs we can assume that they do not conflict which each another. Anything else can be added later.
>
>Thanks,
>Armin Wolf
>
>> 
>>> PS: I'm a developer myself but at lower level kernel domain I'm just a user so hopefully I'm not just adding noise here.
>>> 
>>> - Cody
>> - Derek
>> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ