linux-kernel - Re: [RFC PATCH 0/3] ACPI: platform_profile: Let drivers dynamically refresh 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: <2e71a4a9-6ec6-4ac7-8640-d80dcdfd7776@amd.com>
Date: Tue, 7 Jan 2025 09:51:18 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: Hridesh MG <hridesh699@...il.com>,
 Mark Pearson <mpearson-lenovo@...ebb.ca>
Cc: Kurt Borja <kuurtb@...il.com>,
 "platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>,
 josh@...huagrisham.com, "Derek J . Clark" <derekjohn.clark@...il.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
 Maximilian Luz <luzmaximilian@...il.com>, Hans de Goede
 <hdegoede@...hat.com>, Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>, Lee Chun-Yi <jlee@...e.com>,
 Shyam Sundar S K <Shyam-sundar.S-k@....com>,
 Corentin Chary <corentin.chary@...il.com>, "Luke D . Jones"
 <luke@...nes.dev>, Lyndon Sanche <lsanche@...deno.ca>,
 Ike Panhc <ike.pan@...onical.com>,
 Henrique de Moraes Holschuh <hmh@....eng.br>, Armin Wolf <W_Armin@....de>,
 Colin Ian King <colin.i.king@...il.com>,
 Alexis Belmonte <alexbelm48@...il.com>,
 Uwe Kleine-König <u.kleine-koenig@...libre.com>,
 Ai Chao <aichao@...inos.cn>, Gergo Koteles <soyer@....hu>,
 "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
 linux-kernel@...r.kernel.org, Dell.Client.Kernel@...l.com,
 ibm-acpi-devel@...ts.sourceforge.net
Subject: Re: [RFC PATCH 0/3] ACPI: platform_profile: Let drivers dynamically
 refresh choices

On 1/7/2025 07:14, Hridesh MG wrote:
> On Tue, Jan 7, 2025 at 7:49 AM Mark Pearson <mpearson-lenovo@...ebb.ca> wrote:
>>
>> Hi Kurt,
>>
>> On Sun, Jan 5, 2025, at 11:45 PM, Kurt Borja wrote:
>>> Hello,
>>>
>>> Some drivers may need to dynamically modify their selected `choices`.
>>> Such is the case of the acer-wmi driver, which implemented their own
>>> profile cycling method, because users expect different profiles to be
>>> available whether the laptop is on AC or not [1].
>>>
>>> These series would allow acer-wmi to simplify this custom cycling method
>>> to use platform_profile_cycle(), as it's already being proposed in these
>>> series [2]; without changing expected behaviors, by refreshing their
>>> selected choices on AC connect/disconnect events, which would also solve
>>> this discussion [3].
>>>
>>> Additionally, I think the platform_profile_ops approach would enable us
>>> to hide the platform_profile_handler in the future, and instead just pass
>>> the class device to get/set methods like the HWMON subsystem does.
>>>
>>> I think having this kind of flexibility is valuable. Let me know what you
>>> think!
>>>
>>
>> I personally would love to see how this would be used for the acer issue highlighted to see how it would work out. It feels like the series is short a patch :)
> 
> I do think that having this flexibility would be good, as i was
> considering manually clearing the set bits and calling platform_notify
> for the acer series, but in my specific case (for devices using the
> predator v4 interface) it was found that the hardware was responsive
> to all profiles regardless of AC/battery mode so it made sense to
> leave this kind of artificial limiting of profiles to the
> userspace--similar to how the Windows driver handles it through the
> Nitro Sense app.
> 
> I feel like users should have the power to utilize their hardware in
> the way they want it to, though if there is a compelling reason to
> limit the profiles then i'd be more than happy to add this to the
> series :)
> 
> 
> --
> Hridesh MG

I agree with Mark, this series is missing the patch that shows exactly 
how this would be used.  Furthermore; what exactly are the differences 
in choices between AC or DC?

To "userspace" I fail to understand how "balanced" is different from AC 
to DC for example.

If an implementation has differences for AC vs DC would it make more 
sense to have that abstraction in the "profile handlers" instead of the ops?

IE always have "low-power, balanced, performance" for choices. If the 
system is on AC the profile handler might do something different than on 
DC for a given state.

Another idea I had while thinking about this is that the platform 
profile core can have a sysfs file to indicate whether or not to "allow" 
power state sensitive values.

It could default to "1" and then it can send AC/DC events to the 
platform profile handlers when enabled.  If userspace prefers not to use 
it, then they can set it to 0 and then the profile handler would stop 
reacting.