linux-kernel - Re: [PATCH 1/3] ACPI: platform_profile: Add support for hidden choices

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]

Message-ID: <59634335-9365-454b-8f07-1b8f564e5f29@kernel.org>
Date: Sat, 1 Mar 2025 10:03:10 -0600
From: Mario Limonciello <superm1@...nel.org>
To: Antheas Kapenekakis <lkml@...heas.dev>
Cc: Kurt Borja <kuurtb@...il.com>, Shyam Sundar S K
 <Shyam-sundar.S-k@....com>, "Rafael J . Wysocki" <rafael@...nel.org>,
 Hans de Goede <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 "Luke D . Jones" <luke@...nes.dev>, Mark Pearson
 <mpearson-lenovo@...ebb.ca>,
 "open list:AMD PMF DRIVER" <platform-driver-x86@...r.kernel.org>,
 open list <linux-kernel@...r.kernel.org>,
 "open list:ACPI" <linux-acpi@...r.kernel.org>,
 "Derek J . Clark" <derekjohn.clark@...il.com>, me@...egospodneti.ch,
 Denis Benato <benato.denis96@...il.com>,
 Mario Limonciello <mario.limonciello@....com>, Armin Wolf <W_Armin@....de>
Subject: Re: [PATCH 1/3] ACPI: platform_profile: Add support for hidden
 choices

On 3/1/25 08:06, Antheas Kapenekakis wrote:
> On Sat, 1 Mar 2025 at 14:52, Mario Limonciello <superm1@...nel.org> wrote:
>>
>>>>> Let me know what you think!
>>>>
>>>> I don't really like that profiles can get out of sync, this is asking
>>>> for a non-deterministic behavior that can be difficult to diagnose
>>>> issues and also difficult for userspace to work with.
>>>
>>> I agree with Mario here. Imagine two drivers, one with low-power and
>>> one with quiet. They both begin at performance.
>>>
>>> Then, userspace software gets confused (incl. ppd) and sets firmware
>>> profile to low-power. The latter gets left in performance, causing
>>> excess drain.
>>>
>>> I do not believe the legacy interface should be deprecated. Right now,
>>> amd-pmf is a NOOP in most devices
>>
>> "Most" devices is not accurate.  There are a lot of devices that it does
>> enable.  In the gaming space right now it's often behaving as a no-op.
> 
> That would be a fair description. Can you give some examples of
> devices that use the interface? Devices with and without vendor
> software.

Off hand the Framework 13 and 16 AMD both use PMF exclusively.  So do a 
bunch of HP commercial laptops.

Mark can keep me honest, but I want to say the Strix Thinkpad laptops 
have both PMF and vendor interface (thinkpad-acpi).
  >>
>> "Power mode" is a concept, it doesn't just apply to configuring sPPT and
>> fPPT.  I envisage that a vendor that actively uses PMF and their own
>> interface would be changing different things by the different interfaces.
>>
>> For "example" PMF may reconfigure sPPT, fPPT, STT and STAPM but their
>> driver may notify their EC to change a fan curve.
> 
> No. If PMF changes these values it also needs to change the fan curve
> itself via the BIOS notification. Doing otherwise would lead to
> situations where users do not install the vendor driver and cook their
> device. 

Fan curves are just that; curves.  They just control how quickly fans 
ramp up not whether or not they "work".

But in any case; that's a firmware issue not a platform profile design 
issue.

> So I expect that when PMF controls things it controls
> everything. I would expect if vendors fallback to the pmf firmware
> notifications while also providing vendor software there would be some
> synergy between them, such as changing which fan preset is selected by
> the PMF interface.
> 

I can't control what vendors do; it's their decision how to manage their 
systems.  All I can do is provide infrastructure to help.