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

[Antheas Kapenekakis]

On Fri, 13 Mar 2026 at 20:36, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> First of all, sorry for the huge delay.
>
> This is one of the things that are kind of hard to get to due to other
> stuff going on all the time.

Hi,
thanks for the review. I will go through the emails, asking for
clarifications where appropriate and address the rest out of band. I
am not in a rush irt this series so it is ok from my side.

> On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@xxxxxxxxxxx> wrote:
> >
> > This series introduces a new runtime standby ABI to allow firing Modern
> > Standby firmware notifications that modify hardware appearance from userspace
> > without suspending the kernel. This allows userspace to set the inactivity
> > state of the device so that it looks like it is asleep (e.g., flashing the
> > power button) while still being able to perform basic computations.
>
> I'm not particularly convinced about the "standby" terminology because
> it is easily confused with the "standby" system state defined by ACPI
> (S1).  It is not a similar thing, nor even close.
>
> Admittedly, I was not a fan of the idea to allow user space to trigger
> PNP0D80 device _DSM functions by itself, but now I've changed my mind
> because I can see a valid use case for that.
>
> Namely, if you wanted to indicate to the user that there's no activity
> in the system beyond general maintenance, turning off "lights" would
> be reasonable, but that has a little to do with "standby".  The term
> "dark mode" would be a better match IMV because this is a mode in
> which the system can operate and specifically not a state (the system
> can be in various states, for example working or sleeping, while in
> that mode).

/dark_mode seems a bit verbose/out of place. Perhaps something closer
to activity.

activity_hint / idle_hint perhaps?

> > It is a more fleshed out implementation of [1] and a rewritten version of [2]
> >
> > The first part of this series implements the plumbing that moves the existing
> > DSMs from being called at the end of the suspend sequence to the beginning,
> > where they are called through a transition function. Then, the last patch
> > exposes this transition function through /sys/power/standby to allow userspace
> > to interact with it.
>
> 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

Antheas

> > In this way, the core series can be tested while not exposing the new ABI
> > to userspace until ensured to be stable.
> >
> > For more information, see the first patch in this series with documentation.
> >
> > Because this series is a major rewrite, I have not tested it much and there
> > might be minor logic issues. In addition, due to confusion with the
> > "screen off" terminology, I opted to rename the "screen off" state to
> > "inactive". This way, it is applicable to devices that do not have screens.
> >
> > To test this series, it is recommended to enable logs with:
> >
> > sudo bash -c "cat > /sys/kernel/debug/dynamic_debug/control" << EOF
> > file drivers/acpi/x86/s2idle.c +p
> > file kernel/power/suspend.c +p
> > EOF
> > echo 1 | sudo tee /sys/power/pm_debug_messages
> >
> > Here are some commands afterwards:
> >
> > echo "active" | sudo tee /sys/power/standby; cat /sys/power/standby
> > echo "inactive" | sudo tee /sys/power/standby; cat /sys/power/standby
> > echo "sleep" | sudo tee /sys/power/standby; cat /sys/power/standby
>
> Why do you need the "sleep" thing in addition to /sys/power/state ?
>