Re: [PATCH v1 3/4] platform profile: Add firmware-neutral aggregate sysfs interface

["Mark Pearson" <mpearson-lenovo@squebb.ca>]

On Thu, Oct 15, 2026, at 2:42 PM, Mario Limonciello wrote:
> On 10/15/26 13:33, Rafael J. Wysocki (Intel) wrote:
>> On Thu, Oct 15, 2026 at 8:28 PM Mario Limonciello <superm1@kernel.org> wrote:
>>>
>>> On 10/15/26 13:04, Mark Pearson wrote:
>>>>
>>>> On Thu, Oct 15, 2026, at 7:30 AM, Rafael J. Wysocki (Intel) wrote:
>>>>> On Wed, Oct 14, 2026 at 11:31 PM Armin Wolf <W_Armin@gmx.de> wrote:
>>>>>>
>>>>>> Am 14.10.26 um 15:24 schrieb Daniel Lezcano:
>>>>>>
>>>>>>> The per-provider class interface is firmware-independent, but system-
>>>>>>> wide profile selection is only exposed under /sys/firmware/acpi.
>>>>>>>
>>>>>>> Add /sys/kernel/platform_profile/{choices,profile}, sharing the existing
>>>>>>> aggregate callbacks and semantics with the legacy interface. Keep
>>>>>>> attributes hidden until a provider is registered and remove them after
>>>>>>> the last provider.
>>>>>>>
>>>>>>> Notify both aggregate frontends on profile changes. Also notify the
>>>>>>> provider class device on a direct profile write, matching its documented
>>>>>>> POLLPRI ABI. Restore aggregate visibility after a failed registration.
>>>>>>
>>>>>> IMHO the aggregate sysfs interface only exists for backwards-compatibility,
>>>>>> so i would be very happy if you could just make the associated code optional
>>>>>> and instead teach platform-profiles-daemon to use the individual class devices
>>>>>> instead.
>>>>>
>>>>> It is not just a matter of opinion AFAICS, the aggregate interface has
>>>>> been regarded as legacy for quite a while (see commit 778b94d7ac17
>>>>> "ACPI: platform_profile: Add support for hidden choices" for example)
>>>>> and it was retained exactly for backwards compatibility reasons IIRC.
>>>>>
>>>>> I'm with Armin on this.
>>>>>
>>>>> Thanks!
>>>>
>>>> I don't think we can get rid of the legacy aggregate interface - which I think is what you and Armin are asking for? What does making it optional mean?
>>>>
>>>> Reading through the patch series it seemed quite reasonable to me to move it out from under ACPI but still have the old interface working. What are the alternatives?
>>>>
>>>> User space (and users) are still using the aggregate interface in my experience
>>>>
>>>> Mark
>>>
>>> If we want to get rid of the legacy interface eventually I think this is
>>> how you can do it:
>>>
>>> 1) Wrap it with a boolean Kconfig.  Default to enabled.
>>> 2) Add some messaging in this Kconfig that it's being removed after the
>>> LTS kernel from 2028.
>>> 3) Emit a pr_notice_once() or similar that it's deprecated and will be
>>> removed in the future.
>>> 4) Modify all (known) userspace software to stop using it.
>>> 5) Wait for userspace software to tag new releases.
>>> 6) Change default to disabled.
>>> 7) Wait some time.
>>> 7) Next LTS is declared.
>>> 7) Drop kconfig and legacy code.
>> 
>> That should work, but my point is rather to avoid adding another
>> aggregate interface to replace the old one and instead switch over the
>> ecosystem to the existing (and documented) class device platform
>> profile interface.
>> 
>> The legacy aggregate one may simply be removed when everybody stops
>> using it (which may take a while and it may be moved to staging at one
>> point).
>
> Right totally agreed.  I was meaning userspace software should switch to 
> class interfaces not add a new aggregate one.

OK - I'm in a minority. I will gracefully retreat back under my rock :)

I guess if PPD and tuneD are migrated that will cover 99% of the use cases anyway.

Mark