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

[Rafael J. Wysocki (Intel)]

On Thu, Oct 15, 2026 at 8:28 PM Mario Limonciello <superm1@xxxxxxxxxx> 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@xxxxxx> 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).