Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
From: Antheas Kapenekakis
Date: Mon Mar 23 2026 - 05:32:25 EST
On Mon, 23 Mar 2026 at 05:36, Mario Limonciello <superm1@xxxxxxxxxx> wrote:
>
> > I wouldn't call platform_profile ACPI either, but it just kind of
> > ended up there.
>
> Exactly, it's not the best place for it, but now it's ABI.
>
> > Where would be a better position for it?
>
> I would say it depends upon how generic it ends up being. Maybe
> /sys/kernel if it is very generic. Maybe /sys/power if it's more narrow
> and only going to be for affecting power related things.
When it comes to sysfs, I think that that is clear, as
platform_profiles does not include acpi in its name anymore either.
/sys/class/activity_hint/s2idle/{choices,hint}
Here, I'd prefer hardcoding the name for non-WMI drivers instead of
using a dummy integer such as platform-profile-N to make userspace
implementations easier. For, wmi, <driver_name>-N would be used
instead, mirroring the driver's instantiation name. /name would
provide the definite name in this approach.
The aggregate is a legacy interface, we need not implement it and
defer for later. For an aggregate, perhaps the acpi sysfs is still
more appropriate due to legacy.
The unanswered question remains where in the kernel tree to place it
though. platform_profile nests under drivers/acpi and
firmware_attributes under drivers/platform/x86
Antheas
>
>