[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CAGwozwF9rB85zvp4efqVMTu+4B98R7WSzyE_xCh-TfzbMUPBGQ@mail.gmail.com>
Date: Mon, 24 Feb 2025 22:08:11 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Mark Pearson <mpearson-lenovo@...ebb.ca>
Cc: "Limonciello, Mario" <mario.limonciello@....com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Len Brown <lenb@...nel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
linux-kernel@...r.kernel.org,
"platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>, Hans de Goede <hdegoede@...hat.com>,
me@...egospodneti.ch
Subject: Re: [PATCH 0/3] ACPI: platform_profile: fix legacy sysfs with
multiple handlers
Hi Mark,
My primary focus with this patch series is a bug fix. I imported
Mario's series into our Bazzite 6.13 kernel, only to find it broke
power handling on asus laptops, and it will also do the same on both
legion gos, once a driver exists for those.
And 6.14rc4 is the same. This needs to be fixed before it ships.
This was my attempt at it. I considered other options, like making
amd-pmf implement all profiles. But this seems like too dirty for me.
So I settled at this.
The primary TDP handler of a device is the WMI handler. When that
exists, if one of its options is hidden, that is a regression. It does
not matter the option. If we want amd-pmf to be able to load as a
secondary handler (where the point of that has not been proven to me),
then it (or any other secondary handler) cannot obscure the options of
the primary platform. So it either has to implement all of them, or do
something like this, where it is in between.
Antheas
Powered by blists - more mailing lists