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

[Rafael J. Wysocki (Intel)]

On Thu, Oct 15, 2026 at 8:05 PM Mark Pearson <mpearson-lenovo@xxxxxxxxx> 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?

"Optional" means "not required to be present" AFAIAC.  Which means
making it possible to have a system without that interface and still
exposing the class device platform profile interface.  For example,
when ACPI is disabled.

> 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.

This just means moving things around without a particular gain IMV.

> What are the alternatives?

As per the above, retain it as is for systems where ACPI is enabled
and do not expose it at all otherwise.

> User space (and users) are still using the aggregate interface in my experience

They do use the legacy aggregate interface, but they would need to be
taught to use the new aggregate interface located elsewhere.  However,
they may as well be taught to use the class device platform profile
interface directly, may they not?

IMV, adding a new aggregate interface with all of the problems that
the legacy aggregate interface has would be a mistake.