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

Date: Sat, 11 May 2024 18:14:36 -0600
From: Lyndon Sanche <lsanche@...deno.ca>
To: "Limonciello, Mario" <mario.limonciello@....com>
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



>> 
>>   }
>>     /* dell-rbtn.c driver export functions which will not work 
>> correctly (and could
>> diff --git a/drivers/platform/x86/dell/dell-smbios-base.c 
>> b/drivers/platform/x86/dell/dell-smbios-base.c
>> 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.

My apologies, I accidentally sent my response in HTML format. Please 
see plain-text below:

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?