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

Message-ID: <d12713a2-3b1a-47f1-8173-ec4d675021ec@redhat.com>
Date: Sun, 12 May 2024 17:25:20 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: "Limonciello, Mario" <mario.limonciello@....com>,
 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, 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

Hi,

On 5/12/24 3:43 AM, Limonciello, Mario wrote:
> 
> 
> 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.

Ack this sounds good to me too.

Regards,

Hans