linux-kernel - Re: [PATCH v6 2/2] platform/x86: dell-laptop: Implement platform

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-next>] [day] [month] [year] [list]

Message-ID: <9b652a48-4107-4b68-9aea-6cfdf1e0e4fa@amd.com>
Date: Sat, 11 May 2024 20:43:39 -0500
From: "Limonciello, Mario" <mario.limonciello@....com>
To: Lyndon Sanche <lsanche@...deno.ca>
Cc: pali@...nel.org, W_Armin@....de, srinivas.pandruvada@...ux.intel.com,
 ilpo.jarvinen@...ux.intel.com, lkp@...el.com, hdegoede@...hat.com,
 Yijun.Shen@...l.com, Matthew Garrett <mjg59@...f.ucam.org>,
 Heiner Kallweit <hkallweit1@...il.com>, Randy Dunlap
 <rdunlap@...radead.org>, Jonathan Corbet <corbet@....net>,
 Vegard Nossum <vegard.nossum@...cle.com>,
 platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
 Dell.Client.Kernel@...l.com
Subject: Re: [PATCH v6 2/2] platform/x86: dell-laptop: Implement
 platform_profile



On 5/11/2024 7:12 PM, Lyndon Sanche wrote:
> 
> 
> On Sat, May 11 2024 at 09:59:17 AM -06:00:00, Lyndon Sanche 
> <lsanche@...deno.ca> wrote:
>> On May 11, 2024 9:16:56 a.m. MDT, "Limonciello, Mario" 
>> <mario.limonciello@....com <mailto:mario.limonciello@....com>> wrote:
>>
>>     On 5/10/2024 9:36 PM, Lyndon Sanche wrote:
>>
>>         index 6ae09d7f76fb..387fa5618f7a 100644 ---
>>         a/drivers/platform/x86/dell/dell-smbios-base.c +++
>>         b/drivers/platform/x86/dell/dell-smbios-base.c @@ -71,6 +71,7
>>         @@ static struct smbios_call call_blacklist[] = { /* handled
>>         by kernel: dell-laptop */ {0x0000, CLASS_INFO, SELECT_RFKILL},
>>         {0x0000, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT}, +
>>         {0x0000, CLASS_INFO, SELECT_THERMAL_MANAGEMENT}, }; 
>>
>>     So when Alex checked on v5 that this doesn't load on workstations,
>>     it has made me realize that doing this will block the interface
>>     totally even on workstations. So I think there are a few ways to
>>     go to handle this: 1) Rename dell-laptop to dell-client or dell-pc
>>     and let dell-laptop load on more form factors. This would require
>>     some internal handling in the module for which features make sense
>>     for different form factors. 2) Add a new module just for the
>>     thermal handling and put all this code into it instead. I don't
>>     have a strong opinion, but I do think one of them should be done
>>     to ensure there aren't problems on workstations losing access to
>>     thermal control. 
>>
>> A dell-client/laptop separation makes more sense IMO. I don't think 
>> keyboard control would belong in a the dell-client module either. 
>> Separating just thermal control would be easier, but not as clean I 
>> think. Thanks, Lyndon
> 
> Thinking about it more, we can leave dell-laptop as-is and create a 
> common dell-pc module that does not check for specific form-factors, 
> assuming that is possible. Thermal management can be the first function 
> to go in there.
> 
> We will still block the calls from userspace regardless of which modules 
> are loaded. If dell-pc fails because thermal management is not 
> supported, we aren't losing anything by blocking that call anyway.
> 
> Thoughts?

Sounds good by me.  So basically laptops will load both dell-pc and 
dell-laptop and workstations would load dell-pc.