Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms

[Antheas Kapenekakis]

On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
>
>
>
> On 3/17/26 07:09, Rafael J. Wysocki wrote:
> > On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
> > <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> >>
> >> On 3/16/26 22:52, Antheas Kapenekakis wrote:
> >>>> So in accordance with the above, /sys/power/standby is not a very
> >>>> fortunate choice of the name of this interface and I'm totally
> >>>> unconvinced that it belongs to sys/power because its role is not
> >>>> really power management (and it is ACPI-only for the time being).
> >>> Hm, most of the changes / implementation resides in the pm subsystem
> >>> and it is related to the s2idle suspend flow.
> >>>
> >>> I assume that when it stops being ACPI only provided we reach a design
> >>> that allows for that, the related callbacks would also nest in pm ops.
> >>>
> >>> Where could a more appropriate directory in sysfs be? I would still
> >>> tend towards /sys/power
> >>
> >> Question is whether anyone outside of ACPI will ever need the generic
> >> interface. Making it generic based on guesswork could be a wasted effort
> >> that Rafael and others will have to maintain. The mode file could go
> >> under /sys/firmware/acpi if interface is made ACPI-specific.
> >
> > Well, experience shows that it may end up the other way around.
> >
> > People once thought that the platform profile interface would be
> > ACPI-specific and we ended up having to extend it via
> > platform_profile_class.
> >
> > I'm thinking that something similar may take place in this case.
> > Platforms that don't use ACPI may also want to define platform
> > triggers to somehow adjust platform settings and those may be
> > different from "inactive" or "snooze".
> >
>
> At which point you would almost wonder if this should be super general
> like "foreground_workload_type".
>
> Then this could be expanded for other uses later such as full screen
> video playback or full screen gaming.

Mmm. This reminds me of AMD drm pp_power_profile_mode {BOOTUP_DEFAULT,
3D_FULL_SCREEN, POWER_SAVING, VIDEO, VR, COMPUTE, CUSTOM, WINDOW_3D,
CAPPED, UNCAPPED}. I'm not sure anyone used it. I'd rather avoid the
complexity.

> There could be hooks for scheduler too in the future from this hint too
> then.

Wouldn't it be better to defer to userspace? I'm not sure this would
have a meaningful difference in any case.

The states could be used to power off certain non-MS capable
components that cannot be inferred to be powered off in any case.
E.g., external lights, EC fans, in a centralized way that's tuned by
manufacturers.

Currently, it is adhoc.

> >> Will be good if you could demonstrate a need in making interface
> >> generic, if there are any devices on your mind that could make use of it
> >> right away. Old interface can be deprecated if a better new appears.
> >>
> >> Either way is okay to me, but Rafael is the PM expert and I'd do as he
> >> wants it to be.
> >
> > Thanks, much appreciated.
> >
> > I just want to make one thing clear.  Linux does not implement
> > anything like modern standby and that's for a reason, so I don't want
> > this thing to be advertised as "Linux modern standby" in any shape or
> > form.

Sure.

Antheas