Received-SPF: pass (google.com: domain of linux-kernel+bounces-176915-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <d12713a2-3b1a-47f1-8173-ec4d675021ec@redhat.com>
Date: Sun, 12 May 2024 17:25:20 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/2] platform/x86: dell-laptop: Implement
 platform_profile
To: "Limonciello, Mario" <mario.limonciello@amd.com>,
 Lyndon Sanche <lsanche@lyndeno.ca>
Cc: pali@kernel.org, W_Armin@gmx.de, srinivas.pandruvada@linux.intel.com,
 ilpo.jarvinen@linux.intel.com, lkp@intel.com, Yijun.Shen@dell.com,
 Matthew Garrett <mjg59@srcf.ucam.org>, Heiner Kallweit
 <hkallweit1@gmail.com>, Randy Dunlap <rdunlap@infradead.org>,
 Jonathan Corbet <corbet@lwn.net>, Vegard Nossum <vegard.nossum@oracle.com>,
 platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org,
 Dell.Client.Kernel@dell.com
References: <20240425172758.67831-1-lsanche@lyndeno.ca>
 <20240511023726.7408-4-lsanche@lyndeno.ca>
 <9ba4a500-9d88-4630-bd94-99f07dd51abe@amd.com>
 <B3AA4333-03DC-47D6-9519-7FA9496220E5@lyndeno.ca>
 <48JCDS.E4RT1F9DTKFU1@lyndeno.ca>
 <9b652a48-4107-4b68-9aea-6cfdf1e0e4fa@amd.com>
Content-Language: en-US, nl
From: Hans de Goede <hdegoede@redhat.com>
In-Reply-To: <9b652a48-4107-4b68-9aea-6cfdf1e0e4fa@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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@lyndeno.ca> wrote:
>>> On May 11, 2024 9:16:56 a.m. MDT, "Limonciello, Mario" <mario.limonciello@amd.com <mailto:mario.limonciello@amd.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