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

[Mario Limonciello <superm1@kernel.org>]

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.