* [RFC v1 1/8] Documentation: PM: Add documentation for Runtime Standby States
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2026-03-13 20:07 ` Rafael J. Wysocki
2025-12-26 10:26 ` [RFC v1 2/8] acpi/x86: s2idle: Rename LPS0 constants so they mirror their function Antheas Kapenekakis
` (9 subsequent siblings)
10 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Introduce the runtime standby state ABI, which allows for firing the
Modern Standby firmware notifications found in Windows during runtime.
These notifications allow to make systems that support them look
suspended.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
Documentation/ABI/testing/sysfs-power | 20 ++++
.../admin-guide/pm/standby-states.rst | 100 ++++++++++++++++++
Documentation/admin-guide/pm/system-wide.rst | 1 +
3 files changed, 121 insertions(+)
create mode 100644 Documentation/admin-guide/pm/standby-states.rst
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index d38da077905a..16378be2dc13 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -39,6 +39,26 @@ Description:
See Documentation/admin-guide/pm/sleep-states.rst for more
information.
+What: /sys/power/standby
+Date: February 2026
+Contact: Antheas Kapenekakis <lkml@antheas.dev>
+Description:
+ The /sys/power/standby file allows userspace to inform the
+ kernel of the current runtime standby mode depending on user
+ activity. The options are "active", "inactive", "sleep",
+ and "resume". Only the ones supported by the platform will be
+ available. Depending on the mode, the appearance of the device
+ will change (e.g., keyboard backlight will turn off as part of
+ "inactive"), and its thermal envelope might be affected.
+
+ Reading from this file returns the available standby modes,
+ with the current one enclosed in square brackets. Writing one
+ of the above strings to this file causes the kernel to
+ transition to it.
+
+ See Documentation/admin-guide/pm/standby-states.rst for more
+ information.
+
What: /sys/power/disk
Date: September 2006
Contact: Rafael J. Wysocki <rafael@kernel.org>
diff --git a/Documentation/admin-guide/pm/standby-states.rst b/Documentation/admin-guide/pm/standby-states.rst
new file mode 100644
index 000000000000..af7f32721d1c
--- /dev/null
+++ b/Documentation/admin-guide/pm/standby-states.rst
@@ -0,0 +1,100 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+=====================
+Runtime Standby States
+=====================
+
+:Copyright: |copy| 2026 Antheas Kapenekakis
+
+:Author: Antheas Kapenekakis <lkml@antheas.dev>
+
+This document describes the runtime standby states ABI available in the Linux
+kernel, which is designed as a generic superset of the s0ix/Modern Standby
+firmware notifications. Devices with these notifications support hardware states
+where they look like they are asleep, while still performing basic computation.
+Specifically, those are "Sleep", "Inactive", and "Active" states, with an
+additional state "Resume". Transitioning between these states follows the
+flowchart below.
+
+Runtime Standby States
+==================================
+The following runtime standby are supported::
+
+ <S2idle> ↔ <Sleep> ↔ <Inactive> ↔ <Active>
+ → → <Resume> ↑
+
+.. _s2idle_drips:
+
+
+.. _s2idle_active:
+
+Active
+------
+
+The "Active" state is the default state of the system and the one it has when
+it is turned on. It is the state where the device is on, and the user is
+interacting with it.
+
+.. _s2idle_screen_off:
+
+Inactive
+----------
+
+The "Inactive" state is a state in which users have stopped interacting with
+the device, e.g., 5 seconds after the displays have turned off due to inactivity
+or due to the user pressing the power button. It is the responsibility of
+userspace to keep track of user interaction so it can inform the kernel to
+transition to this state. The response to this state for devices that support
+is to turn off their keyboard backlight, and some might pulse their power light.
+
+.. _s2idle_sleep:
+
+Sleep
+-----
+
+In the sleep state, certain devices will limit their thermal envelope so it is
+safe for them to be put into a bag and still perform basic computation such as
+fetching email. Then, some devices will pulse their power light. Userspace can
+use this state to perform basic tasks such as wake-up checks while maintaining
+the appearance the device is asleep.
+
+.. _s2idle_resume:
+
+Resume
+------
+
+The resume state is a transient state that may only be entered from the sleep
+state. It can be used to notify hardware that the device should boost its
+thermal envelope as preparation for the user interacting with it. As in, it
+undoes the thermal envelope effects of the "sleep" state while keeping its
+appearance.
+
+S2idle
+-----
+
+The "S2idle" state in the diagram corresponds to suspending normally by writing
+``mem`` to ``/sys/power/state``. Userspace is fully frozen, and the kernel parks
+the CPUs and turns off most devices. It is shown in the graph as a reference.
+If the runtime standby state is not "sleep" when entering s2idle, the kernel
+will first transition to "sleep" before entering s2idle.
+
+Basic ``sysfs`` Interface for runtime standby transitions
+=============================================================
+
+The file :file:`/sys/power/standby` can be used to transition the system between
+the different standby states. The file accepts the following values: ``active``,
+``inactive``, ``sleep``, and ``resume``. File writes will block until the
+transition completes. The system will cross all states shown in the flowchart
+above to reach the desired state. It will return ``-EINVAL`` when asking for an
+unsupported state or, e.g., requesting ``resume`` when not in the ``sleep``
+state. If there is an error during the transition, the transition will pause on
+the last error-free state and return an error.
+
+The file can be read to retrieve the current state (and potential ones) with the
+following format: ``[active] inactive sleep resume``. Only supported states
+will be shown.
+
+Userspace may transition between all supported states including s2idle
+arbitrarily, except for the ``resume`` state which may only be requested from
+the ``sleep`` state.
\ No newline at end of file
diff --git a/Documentation/admin-guide/pm/system-wide.rst b/Documentation/admin-guide/pm/system-wide.rst
index 1a1924d71006..411775fae4ac 100644
--- a/Documentation/admin-guide/pm/system-wide.rst
+++ b/Documentation/admin-guide/pm/system-wide.rst
@@ -8,4 +8,5 @@ System-Wide Power Management
:maxdepth: 2
sleep-states
+ standby-states
suspend-flows
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [RFC v1 1/8] Documentation: PM: Add documentation for Runtime Standby States
2025-12-26 10:26 ` [RFC v1 1/8] Documentation: PM: Add documentation for Runtime Standby States Antheas Kapenekakis
@ 2026-03-13 20:07 ` Rafael J. Wysocki
2026-03-16 19:54 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-03-13 20:07 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, rafael, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> Introduce the runtime standby state ABI, which allows for firing the
> Modern Standby firmware notifications found in Windows during runtime.
> These notifications allow to make systems that support them look
> suspended.
The "look suspended" thing is misguided IMV.
I'd rather say something like
This will allow "dark mode" indicating the lack of system activity
related to running user workloads.
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> Documentation/ABI/testing/sysfs-power | 20 ++++
> .../admin-guide/pm/standby-states.rst | 100 ++++++++++++++++++
> Documentation/admin-guide/pm/system-wide.rst | 1 +
> 3 files changed, 121 insertions(+)
> create mode 100644 Documentation/admin-guide/pm/standby-states.rst
>
> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
> index d38da077905a..16378be2dc13 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -39,6 +39,26 @@ Description:
> See Documentation/admin-guide/pm/sleep-states.rst for more
> information.
>
> +What: /sys/power/standby
I've already commented on this in my reply to the cover letter.
> +Date: February 2026
> +Contact: Antheas Kapenekakis <lkml@antheas.dev>
> +Description:
> + The /sys/power/standby file allows userspace to inform the
> + kernel of the current runtime standby mode depending on user
> + activity. The options are "active", "inactive", "sleep",
> + and "resume". Only the ones supported by the platform will be
> + available. Depending on the mode, the appearance of the device
> + will change (e.g., keyboard backlight will turn off as part of
> + "inactive"), and its thermal envelope might be affected.
> +
> + Reading from this file returns the available standby modes,
> + with the current one enclosed in square brackets. Writing one
> + of the above strings to this file causes the kernel to
> + transition to it.
> +
> + See Documentation/admin-guide/pm/standby-states.rst for more
> + information.
> +
> What: /sys/power/disk
> Date: September 2006
> Contact: Rafael J. Wysocki <rafael@kernel.org>
> diff --git a/Documentation/admin-guide/pm/standby-states.rst b/Documentation/admin-guide/pm/standby-states.rst
> new file mode 100644
> index 000000000000..af7f32721d1c
> --- /dev/null
> +++ b/Documentation/admin-guide/pm/standby-states.rst
> @@ -0,0 +1,100 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include:: <isonum.txt>
> +
> +=====================
> +Runtime Standby States
> +=====================
> +
> +:Copyright: |copy| 2026 Antheas Kapenekakis
> +
> +:Author: Antheas Kapenekakis <lkml@antheas.dev>
> +
> +This document describes the runtime standby states ABI available in the Linux
> +kernel, which is designed as a generic superset of the s0ix/Modern Standby
> +firmware notifications. Devices with these notifications support hardware states
> +where they look like they are asleep, while still performing basic computation.
> +Specifically, those are "Sleep", "Inactive", and "Active" states, with an
> +additional state "Resume". Transitioning between these states follows the
> +flowchart below.
> +
> +Runtime Standby States
> +==================================
> +The following runtime standby are supported::
> +
> + <S2idle> ↔ <Sleep> ↔ <Inactive> ↔ <Active>
> + → → <Resume> ↑
> +
> +.. _s2idle_drips:
> +
> +
> +.. _s2idle_active:
> +
> +Active
> +------
> +
> +The "Active" state is the default state of the system and the one it has when
> +it is turned on. It is the state where the device is on, and the user is
> +interacting with it.
> +
> +.. _s2idle_screen_off:
> +
> +Inactive
> +----------
> +
> +The "Inactive" state is a state in which users have stopped interacting with
> +the device, e.g., 5 seconds after the displays have turned off due to inactivity
> +or due to the user pressing the power button. It is the responsibility of
> +userspace to keep track of user interaction so it can inform the kernel to
> +transition to this state. The response to this state for devices that support
> +is to turn off their keyboard backlight, and some might pulse their power light.
> +
> +.. _s2idle_sleep:
> +
> +Sleep
The term "sleep" has already been allocated (sorry about that) and it
means any non-working states of the system, that may include ACPI S3,
ACPI S4 (hibernation), suspend-to-idle etc.
Some other name needs to be used here to avoid confusion with the
existing terminology.
> +-----
> +
> +In the sleep state, certain devices will limit their thermal envelope so it is
> +safe for them to be put into a bag and still perform basic computation such as
> +fetching email. Then, some devices will pulse their power light. Userspace can
> +use this state to perform basic tasks such as wake-up checks while maintaining
> +the appearance the device is asleep.
> +
> +.. _s2idle_resume:
> +
> +Resume
> +------
> +
> +The resume state is a transient state that may only be entered from the sleep
> +state. It can be used to notify hardware that the device should boost its
> +thermal envelope as preparation for the user interacting with it. As in, it
> +undoes the thermal envelope effects of the "sleep" state while keeping its
> +appearance.
> +
> +S2idle
> +-----
> +
> +The "S2idle" state in the diagram corresponds to suspending normally by writing
> +``mem`` to ``/sys/power/state``. Userspace is fully frozen, and the kernel parks
> +the CPUs and turns off most devices. It is shown in the graph as a reference.
> +If the runtime standby state is not "sleep" when entering s2idle, the kernel
> +will first transition to "sleep" before entering s2idle.
Overall, I personally don't like the terminology used above too much.
You seem to be talking about a state machine, but there really isn't
one. The state of the system after evaluating PNP0D80 _DSM function 3
(screen off) need not be different from its preceding state, and even
so the difference may be relatively small.
I would rather describe all of this in terms of indicating certain
conditions to the user. For instance, "inactive" is written to
/sysfs/attribute/to/be/determined to indicate to the user that there's
no activity in the system related to running user workloads.
It's almost like selecting "work profiles" for the platform.
> +
> +Basic ``sysfs`` Interface for runtime standby transitions
> +=============================================================
> +
> +The file :file:`/sys/power/standby` can be used to transition the system between
> +the different standby states.
I'm not sure if the effects of using this interface (or its future
replacement) can be referred to as "transitions". Some devices will
be affected, but the general state of the system will not be changed
as a result of using them.
> The file accepts the following values: ``active``,
> +``inactive``, ``sleep``, and ``resume``. File writes will block until the
> +transition completes. The system will cross all states shown in the flowchart
> +above to reach the desired state. It will return ``-EINVAL`` when asking for an
> +unsupported state or, e.g., requesting ``resume`` when not in the ``sleep``
> +state. If there is an error during the transition, the transition will pause on
> +the last error-free state and return an error.
> +
> +The file can be read to retrieve the current state (and potential ones) with the
> +following format: ``[active] inactive sleep resume``. Only supported states
> +will be shown.
> +
> +Userspace may transition between all supported states including s2idle
> +arbitrarily, except for the ``resume`` state which may only be requested from
> +the ``sleep`` state.
> \ No newline at end of file
> diff --git a/Documentation/admin-guide/pm/system-wide.rst b/Documentation/admin-guide/pm/system-wide.rst
> index 1a1924d71006..411775fae4ac 100644
> --- a/Documentation/admin-guide/pm/system-wide.rst
> +++ b/Documentation/admin-guide/pm/system-wide.rst
> @@ -8,4 +8,5 @@ System-Wide Power Management
> :maxdepth: 2
>
> sleep-states
> + standby-states
> suspend-flows
> --
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 1/8] Documentation: PM: Add documentation for Runtime Standby States
2026-03-13 20:07 ` Rafael J. Wysocki
@ 2026-03-16 19:54 ` Antheas Kapenekakis
0 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 19:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, 13 Mar 2026 at 21:08, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > Introduce the runtime standby state ABI, which allows for firing the
> > Modern Standby firmware notifications found in Windows during runtime.
> > These notifications allow to make systems that support them look
> > suspended.
>
> The "look suspended" thing is misguided IMV.
>
> I'd rather say something like
>
> This will allow "dark mode" indicating the lack of system activity
> related to running user workloads.
>
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > Documentation/ABI/testing/sysfs-power | 20 ++++
> > .../admin-guide/pm/standby-states.rst | 100 ++++++++++++++++++
> > Documentation/admin-guide/pm/system-wide.rst | 1 +
> > 3 files changed, 121 insertions(+)
> > create mode 100644 Documentation/admin-guide/pm/standby-states.rst
> >
> > diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
> > index d38da077905a..16378be2dc13 100644
> > --- a/Documentation/ABI/testing/sysfs-power
> > +++ b/Documentation/ABI/testing/sysfs-power
> > @@ -39,6 +39,26 @@ Description:
> > See Documentation/admin-guide/pm/sleep-states.rst for more
> > information.
> >
> > +What: /sys/power/standby
>
> I've already commented on this in my reply to the cover letter.
>
> > +Date: February 2026
> > +Contact: Antheas Kapenekakis <lkml@antheas.dev>
> > +Description:
> > + The /sys/power/standby file allows userspace to inform the
> > + kernel of the current runtime standby mode depending on user
> > + activity. The options are "active", "inactive", "sleep",
> > + and "resume". Only the ones supported by the platform will be
> > + available. Depending on the mode, the appearance of the device
> > + will change (e.g., keyboard backlight will turn off as part of
> > + "inactive"), and its thermal envelope might be affected.
> > +
> > + Reading from this file returns the available standby modes,
> > + with the current one enclosed in square brackets. Writing one
> > + of the above strings to this file causes the kernel to
> > + transition to it.
> > +
> > + See Documentation/admin-guide/pm/standby-states.rst for more
> > + information.
> > +
> > What: /sys/power/disk
> > Date: September 2006
> > Contact: Rafael J. Wysocki <rafael@kernel.org>
> > diff --git a/Documentation/admin-guide/pm/standby-states.rst b/Documentation/admin-guide/pm/standby-states.rst
> > new file mode 100644
> > index 000000000000..af7f32721d1c
> > --- /dev/null
> > +++ b/Documentation/admin-guide/pm/standby-states.rst
> > @@ -0,0 +1,100 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +.. include:: <isonum.txt>
> > +
> > +=====================
> > +Runtime Standby States
> > +=====================
> > +
> > +:Copyright: |copy| 2026 Antheas Kapenekakis
> > +
> > +:Author: Antheas Kapenekakis <lkml@antheas.dev>
> > +
> > +This document describes the runtime standby states ABI available in the Linux
> > +kernel, which is designed as a generic superset of the s0ix/Modern Standby
> > +firmware notifications. Devices with these notifications support hardware states
> > +where they look like they are asleep, while still performing basic computation.
> > +Specifically, those are "Sleep", "Inactive", and "Active" states, with an
> > +additional state "Resume". Transitioning between these states follows the
> > +flowchart below.
> > +
> > +Runtime Standby States
> > +==================================
> > +The following runtime standby are supported::
> > +
> > + <S2idle> ↔ <Sleep> ↔ <Inactive> ↔ <Active>
> > + → → <Resume> ↑
> > +
> > +.. _s2idle_drips:
> > +
> > +
> > +.. _s2idle_active:
> > +
> > +Active
> > +------
> > +
> > +The "Active" state is the default state of the system and the one it has when
> > +it is turned on. It is the state where the device is on, and the user is
> > +interacting with it.
> > +
> > +.. _s2idle_screen_off:
> > +
> > +Inactive
> > +----------
> > +
> > +The "Inactive" state is a state in which users have stopped interacting with
> > +the device, e.g., 5 seconds after the displays have turned off due to inactivity
> > +or due to the user pressing the power button. It is the responsibility of
> > +userspace to keep track of user interaction so it can inform the kernel to
> > +transition to this state. The response to this state for devices that support
> > +is to turn off their keyboard backlight, and some might pulse their power light.
> > +
> > +.. _s2idle_sleep:
> > +
> > +Sleep
>
> The term "sleep" has already been allocated (sorry about that) and it
> means any non-working states of the system, that may include ACPI S3,
> ACPI S4 (hibernation), suspend-to-idle etc.
>
> Some other name needs to be used here to avoid confusion with the
> existing terminology.
>
> > +-----
> > +
> > +In the sleep state, certain devices will limit their thermal envelope so it is
> > +safe for them to be put into a bag and still perform basic computation such as
> > +fetching email. Then, some devices will pulse their power light. Userspace can
> > +use this state to perform basic tasks such as wake-up checks while maintaining
> > +the appearance the device is asleep.
> > +
> > +.. _s2idle_resume:
> > +
> > +Resume
> > +------
> > +
> > +The resume state is a transient state that may only be entered from the sleep
> > +state. It can be used to notify hardware that the device should boost its
> > +thermal envelope as preparation for the user interacting with it. As in, it
> > +undoes the thermal envelope effects of the "sleep" state while keeping its
> > +appearance.
> > +
> > +S2idle
> > +-----
> > +
> > +The "S2idle" state in the diagram corresponds to suspending normally by writing
> > +``mem`` to ``/sys/power/state``. Userspace is fully frozen, and the kernel parks
> > +the CPUs and turns off most devices. It is shown in the graph as a reference.
> > +If the runtime standby state is not "sleep" when entering s2idle, the kernel
> > +will first transition to "sleep" before entering s2idle.
>
> Overall, I personally don't like the terminology used above too much.
>
> You seem to be talking about a state machine, but there really isn't
> one. The state of the system after evaluating PNP0D80 _DSM function 3
> (screen off) need not be different from its preceding state, and even
> so the difference may be relatively small.
>
> I would rather describe all of this in terms of indicating certain
> conditions to the user. For instance, "inactive" is written to
> /sysfs/attribute/to/be/determined to indicate to the user that there's
> no activity in the system related to running user workloads.
>
> It's almost like selecting "work profiles" for the platform.
The current code implementation is as a state machine. Of course, this
is an implementation detail and need not be exposed to docs.
I will try to reword.
> > +
> > +Basic ``sysfs`` Interface for runtime standby transitions
> > +=============================================================
> > +
> > +The file :file:`/sys/power/standby` can be used to transition the system between
> > +the different standby states.
>
> I'm not sure if the effects of using this interface (or its future
> replacement) can be referred to as "transitions". Some devices will
> be affected, but the general state of the system will not be changed
> as a result of using them.
As said above, the implementation uses transition logic. This is not
needed to be reflected in the documentation.
> > The file accepts the following values: ``active``,
> > +``inactive``, ``sleep``, and ``resume``. File writes will block until the
> > +transition completes. The system will cross all states shown in the flowchart
> > +above to reach the desired state. It will return ``-EINVAL`` when asking for an
> > +unsupported state or, e.g., requesting ``resume`` when not in the ``sleep``
> > +state. If there is an error during the transition, the transition will pause on
> > +the last error-free state and return an error.
> > +
> > +The file can be read to retrieve the current state (and potential ones) with the
> > +following format: ``[active] inactive sleep resume``. Only supported states
> > +will be shown.
> > +
> > +Userspace may transition between all supported states including s2idle
> > +arbitrarily, except for the ``resume`` state which may only be requested from
> > +the ``sleep`` state.
> > \ No newline at end of file
> > diff --git a/Documentation/admin-guide/pm/system-wide.rst b/Documentation/admin-guide/pm/system-wide.rst
> > index 1a1924d71006..411775fae4ac 100644
> > --- a/Documentation/admin-guide/pm/system-wide.rst
> > +++ b/Documentation/admin-guide/pm/system-wide.rst
> > @@ -8,4 +8,5 @@ System-Wide Power Management
> > :maxdepth: 2
> >
> > sleep-states
> > + standby-states
> > suspend-flows
> > --
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [RFC v1 2/8] acpi/x86: s2idle: Rename LPS0 constants so they mirror their function
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
2025-12-26 10:26 ` [RFC v1 1/8] Documentation: PM: Add documentation for Runtime Standby States Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2026-03-13 20:12 ` Rafael J. Wysocki
2025-12-26 10:26 ` [RFC v1 3/8] acpi/x86: s2idle: add runtime standby transition function Antheas Kapenekakis
` (8 subsequent siblings)
10 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
The LPS0 3/4 constants are part of a firmware notification called
"Display on/off", in which the device enters a "Screen Off" state.
The LPS0 7/8 constants are part of a firmware notification in which
a Windows modern standby computer enters a "sleep" state where the
CPU may still be active and maintain the radios.
However, currently, the values are named as "Screen on/off" and "MS
entry/exit", where Modern Standby is abbreviated as "MS". Therefore,
perform a minor rename so that the values match their function. Then,
fix the debug message to say that it executes notifications instead of
entering states as it is otherwise confusing.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/acpi/x86/s2idle.c | 54 +++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 6d4d06236f61..1f13c8b0ef83 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -39,19 +39,19 @@ static const struct acpi_device_id lps0_device_ids[] = {
#define ACPI_LPS0_DSM_UUID "c4eb40a0-6cd2-11e2-bcfd-0800200c9a66"
#define ACPI_LPS0_GET_DEVICE_CONSTRAINTS 1
-#define ACPI_LPS0_SCREEN_OFF 3
-#define ACPI_LPS0_SCREEN_ON 4
+#define ACPI_LPS0_DISPLAY_OFF 3
+#define ACPI_LPS0_DISPLAY_ON 4
#define ACPI_LPS0_ENTRY 5
#define ACPI_LPS0_EXIT 6
-#define ACPI_LPS0_MS_ENTRY 7
-#define ACPI_LPS0_MS_EXIT 8
+#define ACPI_LPS0_SLEEP_ENTRY 7
+#define ACPI_LPS0_SLEEP_EXIT 8
/* AMD */
#define ACPI_LPS0_DSM_UUID_AMD "e3f32452-febc-43ce-9039-932122d37721"
#define ACPI_LPS0_ENTRY_AMD 2
#define ACPI_LPS0_EXIT_AMD 3
-#define ACPI_LPS0_SCREEN_OFF_AMD 4
-#define ACPI_LPS0_SCREEN_ON_AMD 5
+#define ACPI_LPS0_DISPLAY_OFF_AMD 4
+#define ACPI_LPS0_DISPLAY_ON_AMD 5
static acpi_handle lps0_device_handle;
static guid_t lps0_dsm_guid;
@@ -340,25 +340,25 @@ static const char *acpi_sleep_dsm_state_to_str(unsigned int state)
{
if (lps0_dsm_func_mask_microsoft || !acpi_s2idle_vendor_amd()) {
switch (state) {
- case ACPI_LPS0_SCREEN_OFF:
- return "screen off";
- case ACPI_LPS0_SCREEN_ON:
- return "screen on";
+ case ACPI_LPS0_DISPLAY_OFF:
+ return "display off";
+ case ACPI_LPS0_DISPLAY_ON:
+ return "display on";
case ACPI_LPS0_ENTRY:
return "lps0 entry";
case ACPI_LPS0_EXIT:
return "lps0 exit";
- case ACPI_LPS0_MS_ENTRY:
- return "lps0 ms entry";
- case ACPI_LPS0_MS_EXIT:
- return "lps0 ms exit";
+ case ACPI_LPS0_SLEEP_ENTRY:
+ return "sleep entry";
+ case ACPI_LPS0_SLEEP_EXIT:
+ return "sleep exit";
}
} else {
switch (state) {
- case ACPI_LPS0_SCREEN_ON_AMD:
- return "screen on";
- case ACPI_LPS0_SCREEN_OFF_AMD:
- return "screen off";
+ case ACPI_LPS0_DISPLAY_ON_AMD:
+ return "display on";
+ case ACPI_LPS0_DISPLAY_OFF_AMD:
+ return "display off";
case ACPI_LPS0_ENTRY_AMD:
return "lps0 entry";
case ACPI_LPS0_EXIT_AMD:
@@ -383,7 +383,7 @@ static void acpi_sleep_run_lps0_dsm(unsigned int func, unsigned int func_mask, g
lps0_dsm_state = func;
if (pm_debug_messages_on) {
acpi_handle_info(lps0_device_handle,
- "%s transitioned to state %s\n",
+ "%s executed notification %s\n",
out_obj ? "Successfully" : "Failed to",
acpi_sleep_dsm_state_to_str(lps0_dsm_state));
}
@@ -545,12 +545,12 @@ static int acpi_s2idle_prepare_late_lps0(void)
/* Screen off */
if (lps0_dsm_func_mask > 0)
acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
- ACPI_LPS0_SCREEN_OFF_AMD :
- ACPI_LPS0_SCREEN_OFF,
+ ACPI_LPS0_DISPLAY_OFF_AMD :
+ ACPI_LPS0_DISPLAY_OFF,
lps0_dsm_func_mask, lps0_dsm_guid);
if (lps0_dsm_func_mask_microsoft > 0)
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_OFF,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
/* LPS0 entry */
@@ -560,7 +560,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
if (lps0_dsm_func_mask_microsoft > 0) {
/* Modern Standby entry */
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_ENTRY,
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_ENTRY,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
acpi_sleep_run_lps0_dsm(ACPI_LPS0_ENTRY,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
@@ -613,18 +613,18 @@ static void acpi_s2idle_restore_early_lps0(void)
acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
/* Modern Standby exit */
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_EXIT,
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_EXIT,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
}
/* Screen on */
if (lps0_dsm_func_mask_microsoft > 0)
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_ON,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
if (lps0_dsm_func_mask > 0)
acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
- ACPI_LPS0_SCREEN_ON_AMD :
- ACPI_LPS0_SCREEN_ON,
+ ACPI_LPS0_DISPLAY_ON_AMD :
+ ACPI_LPS0_DISPLAY_ON,
lps0_dsm_func_mask, lps0_dsm_guid);
}
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [RFC v1 2/8] acpi/x86: s2idle: Rename LPS0 constants so they mirror their function
2025-12-26 10:26 ` [RFC v1 2/8] acpi/x86: s2idle: Rename LPS0 constants so they mirror their function Antheas Kapenekakis
@ 2026-03-13 20:12 ` Rafael J. Wysocki
2026-03-16 20:01 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-03-13 20:12 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, rafael, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> The LPS0 3/4 constants are part of a firmware notification called
> "Display on/off", in which the device enters a "Screen Off" state.
> The LPS0 7/8 constants are part of a firmware notification in which
> a Windows modern standby computer enters a "sleep" state where the
> CPU may still be active and maintain the radios.
>
> However, currently, the values are named as "Screen on/off"
This is based on the Intel documentation:
https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
> and "MS entry/exit", where Modern Standby is abbreviated as "MS". Therefore,
> perform a minor rename so that the values match their function.
I'm not sure about the first two at least.
> Then, fix the debug message to say that it executes notifications instead of
> entering states as it is otherwise confusing.
>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/acpi/x86/s2idle.c | 54 +++++++++++++++++++--------------------
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index 6d4d06236f61..1f13c8b0ef83 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -39,19 +39,19 @@ static const struct acpi_device_id lps0_device_ids[] = {
> #define ACPI_LPS0_DSM_UUID "c4eb40a0-6cd2-11e2-bcfd-0800200c9a66"
>
> #define ACPI_LPS0_GET_DEVICE_CONSTRAINTS 1
> -#define ACPI_LPS0_SCREEN_OFF 3
> -#define ACPI_LPS0_SCREEN_ON 4
> +#define ACPI_LPS0_DISPLAY_OFF 3
> +#define ACPI_LPS0_DISPLAY_ON 4
> #define ACPI_LPS0_ENTRY 5
> #define ACPI_LPS0_EXIT 6
> -#define ACPI_LPS0_MS_ENTRY 7
> -#define ACPI_LPS0_MS_EXIT 8
> +#define ACPI_LPS0_SLEEP_ENTRY 7
> +#define ACPI_LPS0_SLEEP_EXIT 8
These two renames are fine with me, although I'm not sure if they are
worth the hassle.
>
> /* AMD */
> #define ACPI_LPS0_DSM_UUID_AMD "e3f32452-febc-43ce-9039-932122d37721"
> #define ACPI_LPS0_ENTRY_AMD 2
> #define ACPI_LPS0_EXIT_AMD 3
> -#define ACPI_LPS0_SCREEN_OFF_AMD 4
> -#define ACPI_LPS0_SCREEN_ON_AMD 5
> +#define ACPI_LPS0_DISPLAY_OFF_AMD 4
> +#define ACPI_LPS0_DISPLAY_ON_AMD 5
>
> static acpi_handle lps0_device_handle;
> static guid_t lps0_dsm_guid;
> @@ -340,25 +340,25 @@ static const char *acpi_sleep_dsm_state_to_str(unsigned int state)
> {
> if (lps0_dsm_func_mask_microsoft || !acpi_s2idle_vendor_amd()) {
> switch (state) {
> - case ACPI_LPS0_SCREEN_OFF:
> - return "screen off";
> - case ACPI_LPS0_SCREEN_ON:
> - return "screen on";
> + case ACPI_LPS0_DISPLAY_OFF:
> + return "display off";
> + case ACPI_LPS0_DISPLAY_ON:
> + return "display on";
> case ACPI_LPS0_ENTRY:
> return "lps0 entry";
> case ACPI_LPS0_EXIT:
> return "lps0 exit";
> - case ACPI_LPS0_MS_ENTRY:
> - return "lps0 ms entry";
> - case ACPI_LPS0_MS_EXIT:
> - return "lps0 ms exit";
> + case ACPI_LPS0_SLEEP_ENTRY:
> + return "sleep entry";
> + case ACPI_LPS0_SLEEP_EXIT:
> + return "sleep exit";
> }
> } else {
> switch (state) {
> - case ACPI_LPS0_SCREEN_ON_AMD:
> - return "screen on";
> - case ACPI_LPS0_SCREEN_OFF_AMD:
> - return "screen off";
> + case ACPI_LPS0_DISPLAY_ON_AMD:
> + return "display on";
> + case ACPI_LPS0_DISPLAY_OFF_AMD:
> + return "display off";
> case ACPI_LPS0_ENTRY_AMD:
> return "lps0 entry";
> case ACPI_LPS0_EXIT_AMD:
> @@ -383,7 +383,7 @@ static void acpi_sleep_run_lps0_dsm(unsigned int func, unsigned int func_mask, g
> lps0_dsm_state = func;
> if (pm_debug_messages_on) {
> acpi_handle_info(lps0_device_handle,
> - "%s transitioned to state %s\n",
> + "%s executed notification %s\n",
> out_obj ? "Successfully" : "Failed to",
> acpi_sleep_dsm_state_to_str(lps0_dsm_state));
> }
> @@ -545,12 +545,12 @@ static int acpi_s2idle_prepare_late_lps0(void)
> /* Screen off */
> if (lps0_dsm_func_mask > 0)
> acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> - ACPI_LPS0_SCREEN_OFF_AMD :
> - ACPI_LPS0_SCREEN_OFF,
> + ACPI_LPS0_DISPLAY_OFF_AMD :
> + ACPI_LPS0_DISPLAY_OFF,
> lps0_dsm_func_mask, lps0_dsm_guid);
>
> if (lps0_dsm_func_mask_microsoft > 0)
> - acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
> + acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_OFF,
> lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
>
> /* LPS0 entry */
> @@ -560,7 +560,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
>
> if (lps0_dsm_func_mask_microsoft > 0) {
> /* Modern Standby entry */
> - acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_ENTRY,
> + acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_ENTRY,
> lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> acpi_sleep_run_lps0_dsm(ACPI_LPS0_ENTRY,
> lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> @@ -613,18 +613,18 @@ static void acpi_s2idle_restore_early_lps0(void)
> acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT,
> lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> /* Modern Standby exit */
> - acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_EXIT,
> + acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_EXIT,
> lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> }
>
> /* Screen on */
> if (lps0_dsm_func_mask_microsoft > 0)
> - acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
> + acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_ON,
> lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> if (lps0_dsm_func_mask > 0)
> acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> - ACPI_LPS0_SCREEN_ON_AMD :
> - ACPI_LPS0_SCREEN_ON,
> + ACPI_LPS0_DISPLAY_ON_AMD :
> + ACPI_LPS0_DISPLAY_ON,
> lps0_dsm_func_mask, lps0_dsm_guid);
> }
>
> --
> 2.52.0
>
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 2/8] acpi/x86: s2idle: Rename LPS0 constants so they mirror their function
2026-03-13 20:12 ` Rafael J. Wysocki
@ 2026-03-16 20:01 ` Antheas Kapenekakis
0 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 20:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, 13 Mar 2026 at 21:13, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > The LPS0 3/4 constants are part of a firmware notification called
> > "Display on/off", in which the device enters a "Screen Off" state.
> > The LPS0 7/8 constants are part of a firmware notification in which
> > a Windows modern standby computer enters a "sleep" state where the
> > CPU may still be active and maintain the radios.
> >
> > However, currently, the values are named as "Screen on/off"
>
> This is based on the Intel documentation:
> https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
The intel document affirms the rename, the state is referred to as
"Screen Off" with the callbacks being named "Display On/Off".
> > and "MS entry/exit", where Modern Standby is abbreviated as "MS". Therefore,
> > perform a minor rename so that the values match their function.
>
> I'm not sure about the first two at least.
Sleep DSMs are a bit more complicated. They are only defined in the
Microsoft UUID. However, the Windows suspend flow uses both DSM sets
distinctly. LPS0 entry/exit are used the same way in the Microsoft
UUID. The MS_ pair is used for an intermediary sleep state where the
CPU is still active. As the MS_ prefix causes confusion, I would tend
towards keeping this patch.
> > Then, fix the debug message to say that it executes notifications instead of
> > entering states as it is otherwise confusing.
> >
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > drivers/acpi/x86/s2idle.c | 54 +++++++++++++++++++--------------------
> > 1 file changed, 27 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> > index 6d4d06236f61..1f13c8b0ef83 100644
> > --- a/drivers/acpi/x86/s2idle.c
> > +++ b/drivers/acpi/x86/s2idle.c
> > @@ -39,19 +39,19 @@ static const struct acpi_device_id lps0_device_ids[] = {
> > #define ACPI_LPS0_DSM_UUID "c4eb40a0-6cd2-11e2-bcfd-0800200c9a66"
> >
> > #define ACPI_LPS0_GET_DEVICE_CONSTRAINTS 1
> > -#define ACPI_LPS0_SCREEN_OFF 3
> > -#define ACPI_LPS0_SCREEN_ON 4
> > +#define ACPI_LPS0_DISPLAY_OFF 3
> > +#define ACPI_LPS0_DISPLAY_ON 4
> > #define ACPI_LPS0_ENTRY 5
> > #define ACPI_LPS0_EXIT 6
> > -#define ACPI_LPS0_MS_ENTRY 7
> > -#define ACPI_LPS0_MS_EXIT 8
> > +#define ACPI_LPS0_SLEEP_ENTRY 7
> > +#define ACPI_LPS0_SLEEP_EXIT 8
>
> These two renames are fine with me, although I'm not sure if they are
> worth the hassle.
As you mentioned, sleep is reserved, but as this is the canonical name
in internal code (much like display/screen that will not be exposed in
the ABI) it should be appropriate to keep here.
> >
> > /* AMD */
> > #define ACPI_LPS0_DSM_UUID_AMD "e3f32452-febc-43ce-9039-932122d37721"
> > #define ACPI_LPS0_ENTRY_AMD 2
> > #define ACPI_LPS0_EXIT_AMD 3
> > -#define ACPI_LPS0_SCREEN_OFF_AMD 4
> > -#define ACPI_LPS0_SCREEN_ON_AMD 5
> > +#define ACPI_LPS0_DISPLAY_OFF_AMD 4
> > +#define ACPI_LPS0_DISPLAY_ON_AMD 5
> >
> > static acpi_handle lps0_device_handle;
> > static guid_t lps0_dsm_guid;
> > @@ -340,25 +340,25 @@ static const char *acpi_sleep_dsm_state_to_str(unsigned int state)
> > {
> > if (lps0_dsm_func_mask_microsoft || !acpi_s2idle_vendor_amd()) {
> > switch (state) {
> > - case ACPI_LPS0_SCREEN_OFF:
> > - return "screen off";
> > - case ACPI_LPS0_SCREEN_ON:
> > - return "screen on";
> > + case ACPI_LPS0_DISPLAY_OFF:
> > + return "display off";
> > + case ACPI_LPS0_DISPLAY_ON:
> > + return "display on";
> > case ACPI_LPS0_ENTRY:
> > return "lps0 entry";
> > case ACPI_LPS0_EXIT:
> > return "lps0 exit";
> > - case ACPI_LPS0_MS_ENTRY:
> > - return "lps0 ms entry";
> > - case ACPI_LPS0_MS_EXIT:
> > - return "lps0 ms exit";
> > + case ACPI_LPS0_SLEEP_ENTRY:
> > + return "sleep entry";
> > + case ACPI_LPS0_SLEEP_EXIT:
> > + return "sleep exit";
> > }
> > } else {
> > switch (state) {
> > - case ACPI_LPS0_SCREEN_ON_AMD:
> > - return "screen on";
> > - case ACPI_LPS0_SCREEN_OFF_AMD:
> > - return "screen off";
> > + case ACPI_LPS0_DISPLAY_ON_AMD:
> > + return "display on";
> > + case ACPI_LPS0_DISPLAY_OFF_AMD:
> > + return "display off";
> > case ACPI_LPS0_ENTRY_AMD:
> > return "lps0 entry";
> > case ACPI_LPS0_EXIT_AMD:
> > @@ -383,7 +383,7 @@ static void acpi_sleep_run_lps0_dsm(unsigned int func, unsigned int func_mask, g
> > lps0_dsm_state = func;
> > if (pm_debug_messages_on) {
> > acpi_handle_info(lps0_device_handle,
> > - "%s transitioned to state %s\n",
> > + "%s executed notification %s\n",
> > out_obj ? "Successfully" : "Failed to",
> > acpi_sleep_dsm_state_to_str(lps0_dsm_state));
> > }
> > @@ -545,12 +545,12 @@ static int acpi_s2idle_prepare_late_lps0(void)
> > /* Screen off */
> > if (lps0_dsm_func_mask > 0)
> > acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> > - ACPI_LPS0_SCREEN_OFF_AMD :
> > - ACPI_LPS0_SCREEN_OFF,
> > + ACPI_LPS0_DISPLAY_OFF_AMD :
> > + ACPI_LPS0_DISPLAY_OFF,
> > lps0_dsm_func_mask, lps0_dsm_guid);
> >
> > if (lps0_dsm_func_mask_microsoft > 0)
> > - acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
> > + acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_OFF,
> > lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> >
> > /* LPS0 entry */
> > @@ -560,7 +560,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
> >
> > if (lps0_dsm_func_mask_microsoft > 0) {
> > /* Modern Standby entry */
> > - acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_ENTRY,
> > + acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_ENTRY,
> > lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> > acpi_sleep_run_lps0_dsm(ACPI_LPS0_ENTRY,
> > lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> > @@ -613,18 +613,18 @@ static void acpi_s2idle_restore_early_lps0(void)
> > acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT,
> > lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> > /* Modern Standby exit */
> > - acpi_sleep_run_lps0_dsm(ACPI_LPS0_MS_EXIT,
> > + acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_EXIT,
> > lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> > }
> >
> > /* Screen on */
> > if (lps0_dsm_func_mask_microsoft > 0)
> > - acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
> > + acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_ON,
> > lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> > if (lps0_dsm_func_mask > 0)
> > acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> > - ACPI_LPS0_SCREEN_ON_AMD :
> > - ACPI_LPS0_SCREEN_ON,
> > + ACPI_LPS0_DISPLAY_ON_AMD :
> > + ACPI_LPS0_DISPLAY_ON,
> > lps0_dsm_func_mask, lps0_dsm_guid);
> > }
> >
> > --
> > 2.52.0
> >
> >
> >
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [RFC v1 3/8] acpi/x86: s2idle: add runtime standby transition function
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
2025-12-26 10:26 ` [RFC v1 1/8] Documentation: PM: Add documentation for Runtime Standby States Antheas Kapenekakis
2025-12-26 10:26 ` [RFC v1 2/8] acpi/x86: s2idle: Rename LPS0 constants so they mirror their function Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2026-03-13 20:29 ` Rafael J. Wysocki
2025-12-26 10:26 ` [RFC v1 4/8] acpi/x86: s2idle: add support for querying runtime standby state support Antheas Kapenekakis
` (7 subsequent siblings)
10 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Add pm_standby_transition() to allow transitioning between standby
states during runtime and implement it as part of the s2idle suspend
sequence. Update the platform_s2idle_ops structure to include a function
to perform firmware notifications and a function to get supported states
Standby states are a way for userspace to indicate the interactivity of
the system at the current moment. Active means that the user is
interacting with the device, inactive that a user is not actively
interacting with the device, and sleep that the system should appear as
if it is suspended to the user, but may still perform small
background tasks.
For modern ACPI s0ix laptops, the inactive state turns off the
backlight and the sleep state may limit the thermal envelope of the
device. Either may pulse the power light. This patch introduces an ACPI
agnostic structure to handle these transitions, so they may implemented
by other platforms, and does not implement them for ACPI.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
include/linux/suspend.h | 26 +++++++
kernel/power/suspend.c | 153 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 179 insertions(+)
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index b02876f1ae38..916dee124758 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -40,6 +40,25 @@ typedef int __bitwise suspend_state_t;
#define PM_SUSPEND_MIN PM_SUSPEND_TO_IDLE
#define PM_SUSPEND_MAX ((__force suspend_state_t) 4)
+typedef int __bitwise standby_state_t;
+
+#define PM_STANDBY_ACTIVE ((__force standby_state_t) 0)
+#define PM_STANDBY_INACTIVE ((__force standby_state_t) 1)
+#define PM_STANDBY_SLEEP ((__force standby_state_t) 2)
+#define PM_STANDBY_RESUME ((__force standby_state_t) 3)
+#define PM_STANDBY_MIN PM_STANDBY_ACTIVE
+#define PM_STANDBY_MAX ((__force standby_state_t) 4)
+
+typedef int __bitwise standby_notification_t;
+
+#define PM_SN_INACTIVE_ENTRY ((__force standby_notification_t) 0)
+#define PM_SN_INACTIVE_EXIT ((__force standby_notification_t) 1)
+#define PM_SN_SLEEP_ENTRY ((__force standby_notification_t) 2)
+#define PM_SN_SLEEP_EXIT ((__force standby_notification_t) 3)
+#define PM_SN_RESUME ((__force standby_notification_t) 4)
+#define PM_SN_MIN PM_STANDBY_DISPLAY_OFF
+#define PM_SN_MAX ((__force standby_notification_t) 5)
+
/**
* struct platform_suspend_ops - Callbacks for managing platform dependent
* system sleep states.
@@ -132,6 +151,8 @@ struct platform_suspend_ops {
};
struct platform_s2idle_ops {
+ u8 (*get_standby_states)(void);
+ int (*do_notification)(standby_notification_t state);
int (*begin)(void);
int (*prepare)(void);
int (*prepare_late)(void);
@@ -276,6 +297,11 @@ extern void arch_suspend_enable_irqs(void);
extern int pm_suspend(suspend_state_t state);
extern bool sync_on_suspend_enabled;
+
+extern void pm_standby_refresh_states(void);
+extern int pm_standby_transition(standby_state_t state);
+extern void pm_standby_set_state(standby_state_t state);
+extern int pm_standby_get_state(void);
#else /* !CONFIG_SUSPEND */
#define suspend_valid_only_mem NULL
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 2da4482bb6eb..ede1ba483fa5 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -46,12 +46,21 @@ static const char * const mem_sleep_labels[] = {
[PM_SUSPEND_MEM] = "deep",
};
const char *mem_sleep_states[PM_SUSPEND_MAX];
+static const char * const standby_labels[] = {
+ [PM_STANDBY_ACTIVE] = "active",
+ [PM_STANDBY_INACTIVE] = "inactive",
+ [PM_STANDBY_SLEEP] = "sleep",
+ [PM_STANDBY_RESUME] = "resume",
+};
+const char *standby_states[PM_STANDBY_MAX];
suspend_state_t mem_sleep_current = PM_SUSPEND_TO_IDLE;
suspend_state_t mem_sleep_default = PM_SUSPEND_MAX;
suspend_state_t pm_suspend_target_state;
EXPORT_SYMBOL_GPL(pm_suspend_target_state);
+standby_state_t standby_current = PM_STANDBY_ACTIVE;
+
unsigned int pm_suspend_global_flags;
EXPORT_SYMBOL_GPL(pm_suspend_global_flags);
@@ -195,6 +204,9 @@ void __init pm_states_init(void)
* initialize mem_sleep_states[] accordingly here.
*/
mem_sleep_states[PM_SUSPEND_TO_IDLE] = mem_sleep_labels[PM_SUSPEND_TO_IDLE];
+
+ /* Always support the active runtime standby state. */
+ standby_states[PM_STANDBY_ACTIVE] = standby_labels[PM_STANDBY_ACTIVE];
}
static int __init mem_sleep_default_setup(char *str)
@@ -334,6 +346,141 @@ static bool platform_suspend_again(suspend_state_t state)
suspend_ops->suspend_again() : false;
}
+static int platform_standby_notify(standby_notification_t state)
+{
+ return s2idle_ops && s2idle_ops->do_notification ?
+ s2idle_ops->do_notification(state) :
+ 0;
+}
+
+/**
+ * pm_standby_refresh_states - Refresh the supported runtime standby states
+ */
+void pm_standby_refresh_states(void)
+{
+ u8 standby_support = s2idle_ops && s2idle_ops->get_standby_states ?
+ s2idle_ops->get_standby_states() :
+ 0;
+
+ standby_states[PM_STANDBY_INACTIVE] =
+ standby_support & BIT(PM_STANDBY_INACTIVE) ?
+ standby_labels[PM_STANDBY_INACTIVE] :
+ NULL;
+ standby_states[PM_STANDBY_SLEEP] =
+ standby_support & BIT(PM_STANDBY_SLEEP) ?
+ standby_labels[PM_STANDBY_SLEEP] :
+ NULL;
+ standby_states[PM_STANDBY_RESUME] =
+ standby_support & BIT(PM_STANDBY_RESUME) ?
+ standby_labels[PM_STANDBY_RESUME] :
+ NULL;
+}
+EXPORT_SYMBOL_GPL(pm_standby_refresh_states);
+
+/**
+ * pm_standby_transition - Transition between standby states
+ *
+ * Configure the runtime standby state of the system. Entering these states
+ * may change the appearance of the system (e.g., keyboard backlight) or limit
+ * the thermal envelope of the system (e.g., PLx to 5W).
+ *
+ * Returns an error if the transition fails. The function does not rollback.
+ */
+int pm_standby_transition(standby_state_t state)
+{
+ int error;
+
+ if (state == standby_current)
+ return 0;
+ if (state > PM_STANDBY_MAX)
+ return -EINVAL;
+
+ pm_standby_refresh_states();
+
+ pm_pr_dbg("Transitioning from standby state %s to %s\n",
+ standby_states[standby_current], standby_states[state]);
+
+ /* Resume can only be entered if we are on the sleep state. */
+ if (state == PM_STANDBY_RESUME) {
+ if (standby_current != PM_STANDBY_SLEEP)
+ return -EINVAL;
+ standby_current = PM_STANDBY_RESUME;
+ return platform_standby_notify(PM_SN_RESUME);
+ }
+
+ /*
+ * The system should not be able to re-enter Sleep from resume as it
+ * is undefined behavior. As part of setting the state to "Resume",
+ * userspace promised a transition to "Inactive" or "Active".
+ */
+ if (standby_current == PM_STANDBY_RESUME && state == PM_STANDBY_SLEEP)
+ return -EINVAL;
+
+ /* Resume is the Sleep state logic-wise. */
+ if (standby_current == PM_STANDBY_RESUME)
+ standby_current = PM_STANDBY_SLEEP;
+
+ if (standby_current < state) {
+ for (; standby_current < state; standby_current++) {
+ switch (standby_current + 1) {
+ case PM_STANDBY_INACTIVE:
+ error = platform_standby_notify(PM_SN_INACTIVE_ENTRY);
+ break;
+ case PM_STANDBY_SLEEP:
+ error = platform_standby_notify(PM_SN_SLEEP_ENTRY);
+ break;
+ }
+
+ if (error) {
+ /* Rollback to previous valid state */
+ while (standby_current > PM_STANDBY_ACTIVE &&
+ !standby_states[standby_current])
+ standby_current--;
+ return error;
+ }
+ }
+ } else if (standby_current > state) {
+ for (; standby_current > state; standby_current--) {
+ switch (standby_current) {
+ case PM_STANDBY_SLEEP:
+ error = platform_standby_notify(PM_SN_SLEEP_EXIT);
+ break;
+ case PM_STANDBY_INACTIVE:
+ error = platform_standby_notify(PM_SN_INACTIVE_EXIT);
+ break;
+ }
+
+ if (error) {
+ /* Rollback to previous valid state */
+ while (standby_current < PM_STANDBY_SLEEP &&
+ !standby_states[standby_current])
+ standby_current++;
+ return error;
+ }
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * pm_standby_set_state - Set the current standby state and skip the transition
+ */
+void pm_standby_set_state(standby_state_t state)
+{
+ standby_current = state;
+}
+EXPORT_SYMBOL_GPL(pm_standby_set_state);
+
+/**
+ * pm_standby_get_state - Returns the current standby state
+ */
+int pm_standby_get_state(void)
+{
+ return standby_current;
+}
+EXPORT_SYMBOL_GPL(pm_standby_get_state);
+
#ifdef CONFIG_PM_DEBUG
static unsigned int pm_test_delay = 5;
module_param(pm_test_delay, uint, 0644);
@@ -572,6 +719,7 @@ static void suspend_finish(void)
*/
static int enter_state(suspend_state_t state)
{
+ standby_state_t standby_prior;
int error;
trace_suspend_resume(TPS("suspend_enter"), state, true);
@@ -588,6 +736,9 @@ static int enter_state(suspend_state_t state)
if (!mutex_trylock(&system_transition_mutex))
return -EBUSY;
+ standby_prior = standby_current;
+ pm_standby_transition(PM_STANDBY_SLEEP);
+
if (state == PM_SUSPEND_TO_IDLE)
s2idle_begin();
@@ -619,6 +770,8 @@ static int enter_state(suspend_state_t state)
pm_pr_dbg("Finishing wakeup.\n");
suspend_finish();
Unlock:
+ pm_standby_transition(standby_prior);
+
mutex_unlock(&system_transition_mutex);
return error;
}
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [RFC v1 3/8] acpi/x86: s2idle: add runtime standby transition function
2025-12-26 10:26 ` [RFC v1 3/8] acpi/x86: s2idle: add runtime standby transition function Antheas Kapenekakis
@ 2026-03-13 20:29 ` Rafael J. Wysocki
2026-03-16 20:06 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-03-13 20:29 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, rafael, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> Add pm_standby_transition() to allow transitioning between standby
> states during runtime and implement it as part of the s2idle suspend
> sequence. Update the platform_s2idle_ops structure to include a function
> to perform firmware notifications and a function to get supported states
>
> Standby states are a way for userspace to indicate the interactivity of
> the system at the current moment. Active means that the user is
> interacting with the device, inactive that a user is not actively
> interacting with the device, and sleep that the system should appear as
> if it is suspended to the user, but may still perform small
> background tasks.
>
> For modern ACPI s0ix laptops, the inactive state turns off the
> backlight and the sleep state may limit the thermal envelope of the
> device. Either may pulse the power light. This patch introduces an ACPI
> agnostic structure to handle these transitions, so they may implemented
> by other platforms, and does not implement them for ACPI.
As already stated multiple times, the state-based terminology is not
particularly useful in my view.
I would prefer switching over to condition-indication-based terminology, like
inactive - indicate to the user that there's no activity related to
running user workloads in the system
snooze - indicate to the user that <the above> and the thermal
envelope may have changed
active - the system is active
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> include/linux/suspend.h | 26 +++++++
> kernel/power/suspend.c | 153 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 179 insertions(+)
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index b02876f1ae38..916dee124758 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -40,6 +40,25 @@ typedef int __bitwise suspend_state_t;
> #define PM_SUSPEND_MIN PM_SUSPEND_TO_IDLE
> #define PM_SUSPEND_MAX ((__force suspend_state_t) 4)
>
> +typedef int __bitwise standby_state_t;
> +
> +#define PM_STANDBY_ACTIVE ((__force standby_state_t) 0)
> +#define PM_STANDBY_INACTIVE ((__force standby_state_t) 1)
> +#define PM_STANDBY_SLEEP ((__force standby_state_t) 2)
> +#define PM_STANDBY_RESUME ((__force standby_state_t) 3)
> +#define PM_STANDBY_MIN PM_STANDBY_ACTIVE
> +#define PM_STANDBY_MAX ((__force standby_state_t) 4)
> +
> +typedef int __bitwise standby_notification_t;
> +
> +#define PM_SN_INACTIVE_ENTRY ((__force standby_notification_t) 0)
> +#define PM_SN_INACTIVE_EXIT ((__force standby_notification_t) 1)
> +#define PM_SN_SLEEP_ENTRY ((__force standby_notification_t) 2)
> +#define PM_SN_SLEEP_EXIT ((__force standby_notification_t) 3)
> +#define PM_SN_RESUME ((__force standby_notification_t) 4)
> +#define PM_SN_MIN PM_STANDBY_DISPLAY_OFF
> +#define PM_SN_MAX ((__force standby_notification_t) 5)
> +
> /**
> * struct platform_suspend_ops - Callbacks for managing platform dependent
> * system sleep states.
> @@ -132,6 +151,8 @@ struct platform_suspend_ops {
> };
>
> struct platform_s2idle_ops {
> + u8 (*get_standby_states)(void);
> + int (*do_notification)(standby_notification_t state);
No, this needs to be separate from platform_s2idle_ops and maybe less ad-hoc.
> int (*begin)(void);
> int (*prepare)(void);
> int (*prepare_late)(void);
> @@ -276,6 +297,11 @@ extern void arch_suspend_enable_irqs(void);
>
> extern int pm_suspend(suspend_state_t state);
> extern bool sync_on_suspend_enabled;
> +
> +extern void pm_standby_refresh_states(void);
> +extern int pm_standby_transition(standby_state_t state);
> +extern void pm_standby_set_state(standby_state_t state);
> +extern int pm_standby_get_state(void);
> #else /* !CONFIG_SUSPEND */
> #define suspend_valid_only_mem NULL
>
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 2da4482bb6eb..ede1ba483fa5 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -46,12 +46,21 @@ static const char * const mem_sleep_labels[] = {
> [PM_SUSPEND_MEM] = "deep",
> };
> const char *mem_sleep_states[PM_SUSPEND_MAX];
> +static const char * const standby_labels[] = {
> + [PM_STANDBY_ACTIVE] = "active",
> + [PM_STANDBY_INACTIVE] = "inactive",
> + [PM_STANDBY_SLEEP] = "sleep",
> + [PM_STANDBY_RESUME] = "resume",
> +};
> +const char *standby_states[PM_STANDBY_MAX];
>
> suspend_state_t mem_sleep_current = PM_SUSPEND_TO_IDLE;
> suspend_state_t mem_sleep_default = PM_SUSPEND_MAX;
> suspend_state_t pm_suspend_target_state;
> EXPORT_SYMBOL_GPL(pm_suspend_target_state);
>
> +standby_state_t standby_current = PM_STANDBY_ACTIVE;
> +
> unsigned int pm_suspend_global_flags;
> EXPORT_SYMBOL_GPL(pm_suspend_global_flags);
>
> @@ -195,6 +204,9 @@ void __init pm_states_init(void)
> * initialize mem_sleep_states[] accordingly here.
> */
> mem_sleep_states[PM_SUSPEND_TO_IDLE] = mem_sleep_labels[PM_SUSPEND_TO_IDLE];
> +
> + /* Always support the active runtime standby state. */
> + standby_states[PM_STANDBY_ACTIVE] = standby_labels[PM_STANDBY_ACTIVE];
> }
>
> static int __init mem_sleep_default_setup(char *str)
> @@ -334,6 +346,141 @@ static bool platform_suspend_again(suspend_state_t state)
> suspend_ops->suspend_again() : false;
> }
>
> +static int platform_standby_notify(standby_notification_t state)
> +{
> + return s2idle_ops && s2idle_ops->do_notification ?
> + s2idle_ops->do_notification(state) :
> + 0;
> +}
> +
> +/**
> + * pm_standby_refresh_states - Refresh the supported runtime standby states
> + */
> +void pm_standby_refresh_states(void)
> +{
> + u8 standby_support = s2idle_ops && s2idle_ops->get_standby_states ?
> + s2idle_ops->get_standby_states() :
> + 0;
> +
> + standby_states[PM_STANDBY_INACTIVE] =
> + standby_support & BIT(PM_STANDBY_INACTIVE) ?
> + standby_labels[PM_STANDBY_INACTIVE] :
> + NULL;
> + standby_states[PM_STANDBY_SLEEP] =
> + standby_support & BIT(PM_STANDBY_SLEEP) ?
> + standby_labels[PM_STANDBY_SLEEP] :
> + NULL;
> + standby_states[PM_STANDBY_RESUME] =
> + standby_support & BIT(PM_STANDBY_RESUME) ?
> + standby_labels[PM_STANDBY_RESUME] :
> + NULL;
> +}
> +EXPORT_SYMBOL_GPL(pm_standby_refresh_states);
> +
> +/**
> + * pm_standby_transition - Transition between standby states
> + *
> + * Configure the runtime standby state of the system. Entering these states
> + * may change the appearance of the system (e.g., keyboard backlight) or limit
> + * the thermal envelope of the system (e.g., PLx to 5W).
> + *
> + * Returns an error if the transition fails. The function does not rollback.
> + */
> +int pm_standby_transition(standby_state_t state)
> +{
> + int error;
> +
> + if (state == standby_current)
> + return 0;
> + if (state > PM_STANDBY_MAX)
> + return -EINVAL;
> +
> + pm_standby_refresh_states();
> +
> + pm_pr_dbg("Transitioning from standby state %s to %s\n",
> + standby_states[standby_current], standby_states[state]);
> +
> + /* Resume can only be entered if we are on the sleep state. */
> + if (state == PM_STANDBY_RESUME) {
> + if (standby_current != PM_STANDBY_SLEEP)
> + return -EINVAL;
> + standby_current = PM_STANDBY_RESUME;
> + return platform_standby_notify(PM_SN_RESUME);
> + }
> +
> + /*
> + * The system should not be able to re-enter Sleep from resume as it
> + * is undefined behavior. As part of setting the state to "Resume",
> + * userspace promised a transition to "Inactive" or "Active".
> + */
> + if (standby_current == PM_STANDBY_RESUME && state == PM_STANDBY_SLEEP)
> + return -EINVAL;
> +
> + /* Resume is the Sleep state logic-wise. */
> + if (standby_current == PM_STANDBY_RESUME)
> + standby_current = PM_STANDBY_SLEEP;
> +
> + if (standby_current < state) {
> + for (; standby_current < state; standby_current++) {
> + switch (standby_current + 1) {
> + case PM_STANDBY_INACTIVE:
> + error = platform_standby_notify(PM_SN_INACTIVE_ENTRY);
> + break;
> + case PM_STANDBY_SLEEP:
> + error = platform_standby_notify(PM_SN_SLEEP_ENTRY);
> + break;
> + }
> +
> + if (error) {
> + /* Rollback to previous valid state */
> + while (standby_current > PM_STANDBY_ACTIVE &&
> + !standby_states[standby_current])
> + standby_current--;
> + return error;
> + }
> + }
> + } else if (standby_current > state) {
> + for (; standby_current > state; standby_current--) {
> + switch (standby_current) {
> + case PM_STANDBY_SLEEP:
> + error = platform_standby_notify(PM_SN_SLEEP_EXIT);
> + break;
> + case PM_STANDBY_INACTIVE:
> + error = platform_standby_notify(PM_SN_INACTIVE_EXIT);
> + break;
> + }
> +
> + if (error) {
> + /* Rollback to previous valid state */
> + while (standby_current < PM_STANDBY_SLEEP &&
> + !standby_states[standby_current])
> + standby_current++;
> + return error;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * pm_standby_set_state - Set the current standby state and skip the transition
> + */
> +void pm_standby_set_state(standby_state_t state)
> +{
> + standby_current = state;
> +}
> +EXPORT_SYMBOL_GPL(pm_standby_set_state);
> +
> +/**
> + * pm_standby_get_state - Returns the current standby state
> + */
> +int pm_standby_get_state(void)
> +{
> + return standby_current;
> +}
> +EXPORT_SYMBOL_GPL(pm_standby_get_state);
> +
> #ifdef CONFIG_PM_DEBUG
> static unsigned int pm_test_delay = 5;
> module_param(pm_test_delay, uint, 0644);
> @@ -572,6 +719,7 @@ static void suspend_finish(void)
> */
> static int enter_state(suspend_state_t state)
> {
> + standby_state_t standby_prior;
> int error;
>
> trace_suspend_resume(TPS("suspend_enter"), state, true);
> @@ -588,6 +736,9 @@ static int enter_state(suspend_state_t state)
> if (!mutex_trylock(&system_transition_mutex))
> return -EBUSY;
>
> + standby_prior = standby_current;
> + pm_standby_transition(PM_STANDBY_SLEEP);
I'm not sure if it is actually safe to evaluate PNP0D80 _DSM function
7 (sleep entry notification) at this point because of possible
ordering constraints.
As I said once before in another thread, I would like the platform
notifications to be moved to the places in which you want them to take
place before making any other changes and only once this is proven to
work, further changes can be made.
> +
> if (state == PM_SUSPEND_TO_IDLE)
> s2idle_begin();
>
> @@ -619,6 +770,8 @@ static int enter_state(suspend_state_t state)
> pm_pr_dbg("Finishing wakeup.\n");
> suspend_finish();
> Unlock:
> + pm_standby_transition(standby_prior);
> +
> mutex_unlock(&system_transition_mutex);
> return error;
> }
> --
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 3/8] acpi/x86: s2idle: add runtime standby transition function
2026-03-13 20:29 ` Rafael J. Wysocki
@ 2026-03-16 20:06 ` Antheas Kapenekakis
0 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 20:06 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, 13 Mar 2026 at 21:29, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > Add pm_standby_transition() to allow transitioning between standby
> > states during runtime and implement it as part of the s2idle suspend
> > sequence. Update the platform_s2idle_ops structure to include a function
> > to perform firmware notifications and a function to get supported states
> >
> > Standby states are a way for userspace to indicate the interactivity of
> > the system at the current moment. Active means that the user is
> > interacting with the device, inactive that a user is not actively
> > interacting with the device, and sleep that the system should appear as
> > if it is suspended to the user, but may still perform small
> > background tasks.
> >
> > For modern ACPI s0ix laptops, the inactive state turns off the
> > backlight and the sleep state may limit the thermal envelope of the
> > device. Either may pulse the power light. This patch introduces an ACPI
> > agnostic structure to handle these transitions, so they may implemented
> > by other platforms, and does not implement them for ACPI.
>
> As already stated multiple times, the state-based terminology is not
> particularly useful in my view.
I can reword the commit message. However, here, can you be a bit more
specific? Are you also referring to the underlying implementation? If
yes, how should that change.
If the user goes from active -> snooze, there needs to be a transition
in the underlying implementation (ie we cannot skip the inactive
callbacks).
> I would prefer switching over to condition-indication-based terminology, like
>
> inactive - indicate to the user that there's no activity related to
> running user workloads in the system
> snooze - indicate to the user that <the above> and the thermal
> envelope may have changed
> active - the system is active
>
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > include/linux/suspend.h | 26 +++++++
> > kernel/power/suspend.c | 153 ++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 179 insertions(+)
> >
> > diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> > index b02876f1ae38..916dee124758 100644
> > --- a/include/linux/suspend.h
> > +++ b/include/linux/suspend.h
> > @@ -40,6 +40,25 @@ typedef int __bitwise suspend_state_t;
> > #define PM_SUSPEND_MIN PM_SUSPEND_TO_IDLE
> > #define PM_SUSPEND_MAX ((__force suspend_state_t) 4)
> >
> > +typedef int __bitwise standby_state_t;
> > +
> > +#define PM_STANDBY_ACTIVE ((__force standby_state_t) 0)
> > +#define PM_STANDBY_INACTIVE ((__force standby_state_t) 1)
> > +#define PM_STANDBY_SLEEP ((__force standby_state_t) 2)
> > +#define PM_STANDBY_RESUME ((__force standby_state_t) 3)
> > +#define PM_STANDBY_MIN PM_STANDBY_ACTIVE
> > +#define PM_STANDBY_MAX ((__force standby_state_t) 4)
> > +
> > +typedef int __bitwise standby_notification_t;
> > +
> > +#define PM_SN_INACTIVE_ENTRY ((__force standby_notification_t) 0)
> > +#define PM_SN_INACTIVE_EXIT ((__force standby_notification_t) 1)
> > +#define PM_SN_SLEEP_ENTRY ((__force standby_notification_t) 2)
> > +#define PM_SN_SLEEP_EXIT ((__force standby_notification_t) 3)
> > +#define PM_SN_RESUME ((__force standby_notification_t) 4)
> > +#define PM_SN_MIN PM_STANDBY_DISPLAY_OFF
> > +#define PM_SN_MAX ((__force standby_notification_t) 5)
> > +
> > /**
> > * struct platform_suspend_ops - Callbacks for managing platform dependent
> > * system sleep states.
> > @@ -132,6 +151,8 @@ struct platform_suspend_ops {
> > };
> >
> > struct platform_s2idle_ops {
> > + u8 (*get_standby_states)(void);
> > + int (*do_notification)(standby_notification_t state);
>
> No, this needs to be separate from platform_s2idle_ops and maybe less ad-hoc.
Can you suggest an alternative location? I would prefer to avoid
introducing a new struct.
> > int (*begin)(void);
> > int (*prepare)(void);
> > int (*prepare_late)(void);
> > @@ -276,6 +297,11 @@ extern void arch_suspend_enable_irqs(void);
> >
> > extern int pm_suspend(suspend_state_t state);
> > extern bool sync_on_suspend_enabled;
> > +
> > +extern void pm_standby_refresh_states(void);
> > +extern int pm_standby_transition(standby_state_t state);
> > +extern void pm_standby_set_state(standby_state_t state);
> > +extern int pm_standby_get_state(void);
> > #else /* !CONFIG_SUSPEND */
> > #define suspend_valid_only_mem NULL
> >
> > diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> > index 2da4482bb6eb..ede1ba483fa5 100644
> > --- a/kernel/power/suspend.c
> > +++ b/kernel/power/suspend.c
> > @@ -46,12 +46,21 @@ static const char * const mem_sleep_labels[] = {
> > [PM_SUSPEND_MEM] = "deep",
> > };
> > const char *mem_sleep_states[PM_SUSPEND_MAX];
> > +static const char * const standby_labels[] = {
> > + [PM_STANDBY_ACTIVE] = "active",
> > + [PM_STANDBY_INACTIVE] = "inactive",
> > + [PM_STANDBY_SLEEP] = "sleep",
> > + [PM_STANDBY_RESUME] = "resume",
> > +};
> > +const char *standby_states[PM_STANDBY_MAX];
> >
> > suspend_state_t mem_sleep_current = PM_SUSPEND_TO_IDLE;
> > suspend_state_t mem_sleep_default = PM_SUSPEND_MAX;
> > suspend_state_t pm_suspend_target_state;
> > EXPORT_SYMBOL_GPL(pm_suspend_target_state);
> >
> > +standby_state_t standby_current = PM_STANDBY_ACTIVE;
> > +
> > unsigned int pm_suspend_global_flags;
> > EXPORT_SYMBOL_GPL(pm_suspend_global_flags);
> >
> > @@ -195,6 +204,9 @@ void __init pm_states_init(void)
> > * initialize mem_sleep_states[] accordingly here.
> > */
> > mem_sleep_states[PM_SUSPEND_TO_IDLE] = mem_sleep_labels[PM_SUSPEND_TO_IDLE];
> > +
> > + /* Always support the active runtime standby state. */
> > + standby_states[PM_STANDBY_ACTIVE] = standby_labels[PM_STANDBY_ACTIVE];
> > }
> >
> > static int __init mem_sleep_default_setup(char *str)
> > @@ -334,6 +346,141 @@ static bool platform_suspend_again(suspend_state_t state)
> > suspend_ops->suspend_again() : false;
> > }
> >
> > +static int platform_standby_notify(standby_notification_t state)
> > +{
> > + return s2idle_ops && s2idle_ops->do_notification ?
> > + s2idle_ops->do_notification(state) :
> > + 0;
> > +}
> > +
> > +/**
> > + * pm_standby_refresh_states - Refresh the supported runtime standby states
> > + */
> > +void pm_standby_refresh_states(void)
> > +{
> > + u8 standby_support = s2idle_ops && s2idle_ops->get_standby_states ?
> > + s2idle_ops->get_standby_states() :
> > + 0;
> > +
> > + standby_states[PM_STANDBY_INACTIVE] =
> > + standby_support & BIT(PM_STANDBY_INACTIVE) ?
> > + standby_labels[PM_STANDBY_INACTIVE] :
> > + NULL;
> > + standby_states[PM_STANDBY_SLEEP] =
> > + standby_support & BIT(PM_STANDBY_SLEEP) ?
> > + standby_labels[PM_STANDBY_SLEEP] :
> > + NULL;
> > + standby_states[PM_STANDBY_RESUME] =
> > + standby_support & BIT(PM_STANDBY_RESUME) ?
> > + standby_labels[PM_STANDBY_RESUME] :
> > + NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(pm_standby_refresh_states);
> > +
> > +/**
> > + * pm_standby_transition - Transition between standby states
> > + *
> > + * Configure the runtime standby state of the system. Entering these states
> > + * may change the appearance of the system (e.g., keyboard backlight) or limit
> > + * the thermal envelope of the system (e.g., PLx to 5W).
> > + *
> > + * Returns an error if the transition fails. The function does not rollback.
> > + */
> > +int pm_standby_transition(standby_state_t state)
> > +{
> > + int error;
> > +
> > + if (state == standby_current)
> > + return 0;
> > + if (state > PM_STANDBY_MAX)
> > + return -EINVAL;
> > +
> > + pm_standby_refresh_states();
> > +
> > + pm_pr_dbg("Transitioning from standby state %s to %s\n",
> > + standby_states[standby_current], standby_states[state]);
> > +
> > + /* Resume can only be entered if we are on the sleep state. */
> > + if (state == PM_STANDBY_RESUME) {
> > + if (standby_current != PM_STANDBY_SLEEP)
> > + return -EINVAL;
> > + standby_current = PM_STANDBY_RESUME;
> > + return platform_standby_notify(PM_SN_RESUME);
> > + }
> > +
> > + /*
> > + * The system should not be able to re-enter Sleep from resume as it
> > + * is undefined behavior. As part of setting the state to "Resume",
> > + * userspace promised a transition to "Inactive" or "Active".
> > + */
> > + if (standby_current == PM_STANDBY_RESUME && state == PM_STANDBY_SLEEP)
> > + return -EINVAL;
> > +
> > + /* Resume is the Sleep state logic-wise. */
> > + if (standby_current == PM_STANDBY_RESUME)
> > + standby_current = PM_STANDBY_SLEEP;
> > +
> > + if (standby_current < state) {
> > + for (; standby_current < state; standby_current++) {
> > + switch (standby_current + 1) {
> > + case PM_STANDBY_INACTIVE:
> > + error = platform_standby_notify(PM_SN_INACTIVE_ENTRY);
> > + break;
> > + case PM_STANDBY_SLEEP:
> > + error = platform_standby_notify(PM_SN_SLEEP_ENTRY);
> > + break;
> > + }
> > +
> > + if (error) {
> > + /* Rollback to previous valid state */
> > + while (standby_current > PM_STANDBY_ACTIVE &&
> > + !standby_states[standby_current])
> > + standby_current--;
> > + return error;
> > + }
> > + }
> > + } else if (standby_current > state) {
> > + for (; standby_current > state; standby_current--) {
> > + switch (standby_current) {
> > + case PM_STANDBY_SLEEP:
> > + error = platform_standby_notify(PM_SN_SLEEP_EXIT);
> > + break;
> > + case PM_STANDBY_INACTIVE:
> > + error = platform_standby_notify(PM_SN_INACTIVE_EXIT);
> > + break;
> > + }
> > +
> > + if (error) {
> > + /* Rollback to previous valid state */
> > + while (standby_current < PM_STANDBY_SLEEP &&
> > + !standby_states[standby_current])
> > + standby_current++;
> > + return error;
> > + }
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * pm_standby_set_state - Set the current standby state and skip the transition
> > + */
> > +void pm_standby_set_state(standby_state_t state)
> > +{
> > + standby_current = state;
> > +}
> > +EXPORT_SYMBOL_GPL(pm_standby_set_state);
> > +
> > +/**
> > + * pm_standby_get_state - Returns the current standby state
> > + */
> > +int pm_standby_get_state(void)
> > +{
> > + return standby_current;
> > +}
> > +EXPORT_SYMBOL_GPL(pm_standby_get_state);
> > +
> > #ifdef CONFIG_PM_DEBUG
> > static unsigned int pm_test_delay = 5;
> > module_param(pm_test_delay, uint, 0644);
> > @@ -572,6 +719,7 @@ static void suspend_finish(void)
> > */
> > static int enter_state(suspend_state_t state)
> > {
> > + standby_state_t standby_prior;
> > int error;
> >
> > trace_suspend_resume(TPS("suspend_enter"), state, true);
> > @@ -588,6 +736,9 @@ static int enter_state(suspend_state_t state)
> > if (!mutex_trylock(&system_transition_mutex))
> > return -EBUSY;
> >
> > + standby_prior = standby_current;
> > + pm_standby_transition(PM_STANDBY_SLEEP);
>
> I'm not sure if it is actually safe to evaluate PNP0D80 _DSM function
> 7 (sleep entry notification) at this point because of possible
> ordering constraints.
>
> As I said once before in another thread, I would like the platform
> notifications to be moved to the places in which you want them to take
> place before making any other changes and only once this is proven to
> work, further changes can be made.
Following the conclusion of this discussion I can spin a non-RFC
keeping the rename and doing a simple re-ordering, plus cleaning up
the asus related code for the Ally so that it works correctly. This
way, the re-ordering can be tested individually and merged first.
Antheas
> > +
> > if (state == PM_SUSPEND_TO_IDLE)
> > s2idle_begin();
> >
> > @@ -619,6 +770,8 @@ static int enter_state(suspend_state_t state)
> > pm_pr_dbg("Finishing wakeup.\n");
> > suspend_finish();
> > Unlock:
> > + pm_standby_transition(standby_prior);
> > +
> > mutex_unlock(&system_transition_mutex);
> > return error;
> > }
> > --
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [RFC v1 4/8] acpi/x86: s2idle: add support for querying runtime standby state support
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (2 preceding siblings ...)
2025-12-26 10:26 ` [RFC v1 3/8] acpi/x86: s2idle: add runtime standby transition function Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2025-12-26 10:26 ` [RFC v1 5/8] acpi/x86: s2idle: move DSM notifications to do_notification callback Antheas Kapenekakis
` (6 subsequent siblings)
10 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Implement the platform_s2idle_ops->get_standby_states() callback to
query which modern standby states are supported by the platform based
on the dsm func masks and expose those to the kernel as runtime standby
states. Union the vendor specific AMD/Intel masks with the ones from
Microsoft as some laptops implement both of them.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/acpi/x86/s2idle.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 1f13c8b0ef83..08fa7841a484 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -513,6 +513,40 @@ static struct acpi_scan_handler lps0_handler = {
.attach = lps0_device_attach,
};
+static u8 acpi_s2idle_get_standby_states(void)
+{
+ u8 states = 0;
+
+ if (!lps0_device_handle || sleep_no_lps0)
+ return 0;
+
+ if (lps0_dsm_func_mask_microsoft > 0) {
+ states |= BIT(PM_STANDBY_ACTIVE);
+ if (lps0_dsm_func_mask_microsoft &
+ (1 << ACPI_LPS0_DISPLAY_OFF | 1 << ACPI_LPS0_DISPLAY_ON))
+ states |= BIT(PM_STANDBY_INACTIVE);
+ if (lps0_dsm_func_mask_microsoft &
+ (1 << ACPI_LPS0_SLEEP_ENTRY | 1 << ACPI_LPS0_SLEEP_EXIT))
+ states |= BIT(PM_STANDBY_SLEEP);
+ }
+
+ if (lps0_dsm_func_mask > 0) {
+ states |= BIT(PM_STANDBY_ACTIVE);
+ if (acpi_s2idle_vendor_amd()) {
+ if (lps0_dsm_func_mask &
+ (1 << ACPI_LPS0_DISPLAY_OFF_AMD |
+ 1 << ACPI_LPS0_DISPLAY_ON_AMD))
+ states |= BIT(PM_STANDBY_INACTIVE);
+ } else {
+ if (lps0_dsm_func_mask & (1 << ACPI_LPS0_DISPLAY_OFF |
+ 1 << ACPI_LPS0_DISPLAY_ON))
+ states |= BIT(PM_STANDBY_INACTIVE);
+ }
+ }
+
+ return states;
+}
+
static int acpi_s2idle_begin_lps0(void)
{
if (pm_debug_messages_on && !lpi_constraints_table) {
@@ -629,6 +663,7 @@ static void acpi_s2idle_restore_early_lps0(void)
}
static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
+ .get_standby_states = acpi_s2idle_get_standby_states,
.begin = acpi_s2idle_begin_lps0,
.prepare = acpi_s2idle_prepare,
.prepare_late = acpi_s2idle_prepare_late_lps0,
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* [RFC v1 5/8] acpi/x86: s2idle: move DSM notifications to do_notification callback
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (3 preceding siblings ...)
2025-12-26 10:26 ` [RFC v1 4/8] acpi/x86: s2idle: add support for querying runtime standby state support Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2025-12-26 10:26 ` [RFC v1 6/8] acpi/x86: s2idle: implement turn on display DSM as resume notification Antheas Kapenekakis
` (5 subsequent siblings)
10 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Currently, the DSM Sleep Entry/Exit/Display On/Off notifications fire
during the suspend sequence. Move them to the new do_notification
callback so they can be called during runtime as well. The kernel will
still ensure that they are called during s2idle without userspace
involvement.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/acpi/x86/s2idle.c | 87 +++++++++++++++++++++++----------------
1 file changed, 52 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 08fa7841a484..7693162c68fd 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -547,6 +547,53 @@ static u8 acpi_s2idle_get_standby_states(void)
return states;
}
+static int acpi_s2idle_do_notification(standby_notification_t state)
+{
+ switch ((__force unsigned int)state) {
+ case PM_SN_INACTIVE_ENTRY:
+ if (lps0_dsm_func_mask > 0)
+ acpi_sleep_run_lps0_dsm(
+ acpi_s2idle_vendor_amd() ?
+ ACPI_LPS0_DISPLAY_OFF_AMD :
+ ACPI_LPS0_DISPLAY_OFF,
+ lps0_dsm_func_mask, lps0_dsm_guid);
+
+ if (lps0_dsm_func_mask_microsoft > 0)
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_OFF,
+ lps0_dsm_func_mask_microsoft,
+ lps0_dsm_guid_microsoft);
+ break;
+ case PM_SN_INACTIVE_EXIT:
+ if (lps0_dsm_func_mask > 0)
+ acpi_sleep_run_lps0_dsm(
+ acpi_s2idle_vendor_amd() ?
+ ACPI_LPS0_DISPLAY_ON_AMD :
+ ACPI_LPS0_DISPLAY_ON,
+ lps0_dsm_func_mask, lps0_dsm_guid);
+ if (lps0_dsm_func_mask_microsoft > 0)
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_ON,
+ lps0_dsm_func_mask_microsoft,
+ lps0_dsm_guid_microsoft);
+ break;
+ case PM_SN_SLEEP_ENTRY:
+ if (lps0_dsm_func_mask_microsoft > 0)
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_ENTRY,
+ lps0_dsm_func_mask_microsoft,
+ lps0_dsm_guid_microsoft);
+ break;
+ case PM_SN_SLEEP_EXIT:
+ if (lps0_dsm_func_mask_microsoft > 0)
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_EXIT,
+ lps0_dsm_func_mask_microsoft,
+ lps0_dsm_guid_microsoft);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int acpi_s2idle_begin_lps0(void)
{
if (pm_debug_messages_on && !lpi_constraints_table) {
@@ -576,33 +623,16 @@ static int acpi_s2idle_prepare_late_lps0(void)
if (pm_debug_messages_on)
lpi_check_constraints();
- /* Screen off */
+ /* LPS0 entry */
if (lps0_dsm_func_mask > 0)
acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
- ACPI_LPS0_DISPLAY_OFF_AMD :
- ACPI_LPS0_DISPLAY_OFF,
+ ACPI_LPS0_ENTRY_AMD :
+ ACPI_LPS0_ENTRY,
lps0_dsm_func_mask, lps0_dsm_guid);
if (lps0_dsm_func_mask_microsoft > 0)
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_OFF,
- lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
-
- /* LPS0 entry */
- if (lps0_dsm_func_mask > 0 && acpi_s2idle_vendor_amd())
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_ENTRY_AMD,
- lps0_dsm_func_mask, lps0_dsm_guid);
-
- if (lps0_dsm_func_mask_microsoft > 0) {
- /* Modern Standby entry */
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_ENTRY,
- lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
acpi_sleep_run_lps0_dsm(ACPI_LPS0_ENTRY,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
- }
-
- if (lps0_dsm_func_mask > 0 && !acpi_s2idle_vendor_amd())
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_ENTRY,
- lps0_dsm_func_mask, lps0_dsm_guid);
list_for_each_entry(handler, &lps0_s2idle_devops_head, list_node) {
if (handler->prepare)
@@ -643,27 +673,14 @@ static void acpi_s2idle_restore_early_lps0(void)
ACPI_LPS0_EXIT,
lps0_dsm_func_mask, lps0_dsm_guid);
- if (lps0_dsm_func_mask_microsoft > 0) {
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT,
- lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
- /* Modern Standby exit */
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_SLEEP_EXIT,
- lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
- }
-
- /* Screen on */
if (lps0_dsm_func_mask_microsoft > 0)
- acpi_sleep_run_lps0_dsm(ACPI_LPS0_DISPLAY_ON,
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT,
lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
- if (lps0_dsm_func_mask > 0)
- acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
- ACPI_LPS0_DISPLAY_ON_AMD :
- ACPI_LPS0_DISPLAY_ON,
- lps0_dsm_func_mask, lps0_dsm_guid);
}
static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
.get_standby_states = acpi_s2idle_get_standby_states,
+ .do_notification = acpi_s2idle_do_notification,
.begin = acpi_s2idle_begin_lps0,
.prepare = acpi_s2idle_prepare,
.prepare_late = acpi_s2idle_prepare_late_lps0,
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* [RFC v1 6/8] acpi/x86: s2idle: implement turn on display DSM as resume notification
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (4 preceding siblings ...)
2025-12-26 10:26 ` [RFC v1 5/8] acpi/x86: s2idle: move DSM notifications to do_notification callback Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2025-12-26 10:26 ` [RFC v1 7/8] PM: hibernate: Enter s2idle sleep state before hibernation Antheas Kapenekakis
` (4 subsequent siblings)
10 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Windows implements a DSM called "Turn On Display". This notification is
sent to the hardware while on the sleep state if the user interacted
with the device and caused it to wake up in such a way where the display
should turn on.
This allows the OEM to counter the effects of Sleep entry such as a
reduced power envelope to allow for the device to wake up faster.
Implement it as part of the "resume" state in the Microsoft-agnostic
kernel ABI.
Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/acpi/x86/s2idle.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 7693162c68fd..965b78cc8bf5 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -39,12 +39,13 @@ static const struct acpi_device_id lps0_device_ids[] = {
#define ACPI_LPS0_DSM_UUID "c4eb40a0-6cd2-11e2-bcfd-0800200c9a66"
#define ACPI_LPS0_GET_DEVICE_CONSTRAINTS 1
-#define ACPI_LPS0_DISPLAY_OFF 3
-#define ACPI_LPS0_DISPLAY_ON 4
-#define ACPI_LPS0_ENTRY 5
-#define ACPI_LPS0_EXIT 6
-#define ACPI_LPS0_SLEEP_ENTRY 7
-#define ACPI_LPS0_SLEEP_EXIT 8
+#define ACPI_LPS0_DISPLAY_OFF 3
+#define ACPI_LPS0_DISPLAY_ON 4
+#define ACPI_LPS0_ENTRY 5
+#define ACPI_LPS0_EXIT 6
+#define ACPI_LPS0_SLEEP_ENTRY 7
+#define ACPI_LPS0_SLEEP_EXIT 8
+#define ACPI_LPS0_TURN_ON_DISPLAY 9
/* AMD */
#define ACPI_LPS0_DSM_UUID_AMD "e3f32452-febc-43ce-9039-932122d37721"
@@ -352,6 +353,8 @@ static const char *acpi_sleep_dsm_state_to_str(unsigned int state)
return "sleep entry";
case ACPI_LPS0_SLEEP_EXIT:
return "sleep exit";
+ case ACPI_LPS0_TURN_ON_DISPLAY:
+ return "turn on display";
}
} else {
switch (state) {
@@ -528,6 +531,9 @@ static u8 acpi_s2idle_get_standby_states(void)
if (lps0_dsm_func_mask_microsoft &
(1 << ACPI_LPS0_SLEEP_ENTRY | 1 << ACPI_LPS0_SLEEP_EXIT))
states |= BIT(PM_STANDBY_SLEEP);
+ if (lps0_dsm_func_mask_microsoft &
+ (1 << ACPI_LPS0_TURN_ON_DISPLAY))
+ states |= BIT(PM_STANDBY_RESUME);
}
if (lps0_dsm_func_mask > 0) {
@@ -587,6 +593,12 @@ static int acpi_s2idle_do_notification(standby_notification_t state)
lps0_dsm_func_mask_microsoft,
lps0_dsm_guid_microsoft);
break;
+ case PM_SN_RESUME:
+ if (lps0_dsm_func_mask_microsoft > 0)
+ acpi_sleep_run_lps0_dsm(ACPI_LPS0_TURN_ON_DISPLAY,
+ lps0_dsm_func_mask_microsoft,
+ lps0_dsm_guid_microsoft);
+ break;
default:
return -EINVAL;
}
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* [RFC v1 7/8] PM: hibernate: Enter s2idle sleep state before hibernation
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (5 preceding siblings ...)
2025-12-26 10:26 ` [RFC v1 6/8] acpi/x86: s2idle: implement turn on display DSM as resume notification Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2026-03-13 20:33 ` Rafael J. Wysocki
2025-12-26 10:26 ` [RFC v1 8/8] PM: standby: Add sysfs attribute for runtime standby transitions Antheas Kapenekakis
` (3 subsequent siblings)
10 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Implement the standby states as part of hibernation. Specifically,
ensure we are in the inactive state before hibernation entry, and
sync the state as active after hibernation resume. In case of a failed
hibernation, restore the previous standby state.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
kernel/power/hibernate.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index af8d07bafe02..85a5ca8f6537 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -787,7 +787,11 @@ static int load_image_and_restore(void)
*/
int hibernate(void)
{
+#ifdef CONFIG_SUSPEND
+ standby_state_t previous_standby;
+#endif
bool snapshot_test = false;
+ bool powered_down = false;
unsigned int sleep_flags;
int error;
@@ -815,6 +819,13 @@ int hibernate(void)
}
pr_info("hibernation entry\n");
+
+#if CONFIG_SUSPEND
+ /* Enter the standby screen off state in case userspace has not. */
+ previous_standby = pm_standby_get_state();
+ pm_standby_transition(PM_STANDBY_INACTIVE);
+#endif
+
pm_prepare_console();
error = pm_notifier_call_chain_robust(PM_HIBERNATION_PREPARE, PM_POST_HIBERNATION);
if (error)
@@ -867,10 +878,12 @@ int hibernate(void)
error = swsusp_write(flags);
swsusp_free();
if (!error) {
- if (hibernation_mode == HIBERNATION_TEST_RESUME)
+ if (hibernation_mode == HIBERNATION_TEST_RESUME) {
snapshot_test = true;
- else
+ } else {
+ powered_down = true;
power_down();
+ }
}
in_suspend = 0;
pm_restore_gfp_mask();
@@ -897,6 +910,18 @@ int hibernate(void)
Notify:
pm_notifier_call_chain(PM_POST_HIBERNATION);
Restore:
+#if CONFIG_SUSPEND
+ /*
+ * If we resumed from S5, we are in the active standby state. However,
+ * the kernel restored a stale value. Sync it. Otherwise, in e.g., the
+ * case of a failed hibernation, transition to the previous value.
+ */
+ if (powered_down)
+ pm_standby_set_state(PM_STANDBY_ACTIVE);
+ else
+ pm_standby_transition(previous_standby);
+#endif
+
pm_restore_console();
hibernate_release();
Unlock:
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [RFC v1 7/8] PM: hibernate: Enter s2idle sleep state before hibernation
2025-12-26 10:26 ` [RFC v1 7/8] PM: hibernate: Enter s2idle sleep state before hibernation Antheas Kapenekakis
@ 2026-03-13 20:33 ` Rafael J. Wysocki
2026-03-16 20:09 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-03-13 20:33 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, rafael, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> Implement the standby states as part of hibernation. Specifically,
> ensure we are in the inactive state before hibernation entry, and
> sync the state as active after hibernation resume. In case of a failed
> hibernation, restore the previous standby state.
We've not mixed up "modern standby" _DSM calls with hibernation so
far, so this change is potentially risky.
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> kernel/power/hibernate.c | 29 +++++++++++++++++++++++++++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index af8d07bafe02..85a5ca8f6537 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -787,7 +787,11 @@ static int load_image_and_restore(void)
> */
> int hibernate(void)
> {
> +#ifdef CONFIG_SUSPEND
> + standby_state_t previous_standby;
> +#endif
> bool snapshot_test = false;
> + bool powered_down = false;
> unsigned int sleep_flags;
> int error;
>
> @@ -815,6 +819,13 @@ int hibernate(void)
> }
>
> pr_info("hibernation entry\n");
> +
> +#if CONFIG_SUSPEND
> + /* Enter the standby screen off state in case userspace has not. */
> + previous_standby = pm_standby_get_state();
> + pm_standby_transition(PM_STANDBY_INACTIVE);
> +#endif
> +
> pm_prepare_console();
> error = pm_notifier_call_chain_robust(PM_HIBERNATION_PREPARE, PM_POST_HIBERNATION);
> if (error)
> @@ -867,10 +878,12 @@ int hibernate(void)
> error = swsusp_write(flags);
> swsusp_free();
> if (!error) {
> - if (hibernation_mode == HIBERNATION_TEST_RESUME)
> + if (hibernation_mode == HIBERNATION_TEST_RESUME) {
> snapshot_test = true;
> - else
> + } else {
> + powered_down = true;
> power_down();
> + }
> }
> in_suspend = 0;
> pm_restore_gfp_mask();
> @@ -897,6 +910,18 @@ int hibernate(void)
> Notify:
> pm_notifier_call_chain(PM_POST_HIBERNATION);
> Restore:
> +#if CONFIG_SUSPEND
> + /*
> + * If we resumed from S5, we are in the active standby state. However,
> + * the kernel restored a stale value. Sync it. Otherwise, in e.g., the
> + * case of a failed hibernation, transition to the previous value.
> + */
> + if (powered_down)
> + pm_standby_set_state(PM_STANDBY_ACTIVE);
> + else
> + pm_standby_transition(previous_standby);
> +#endif
> +
> pm_restore_console();
> hibernate_release();
> Unlock:
> --
> 2.52.0
>
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 7/8] PM: hibernate: Enter s2idle sleep state before hibernation
2026-03-13 20:33 ` Rafael J. Wysocki
@ 2026-03-16 20:09 ` Antheas Kapenekakis
0 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 20:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, 13 Mar 2026 at 21:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > Implement the standby states as part of hibernation. Specifically,
> > ensure we are in the inactive state before hibernation entry, and
> > sync the state as active after hibernation resume. In case of a failed
> > hibernation, restore the previous standby state.
>
> We've not mixed up "modern standby" _DSM calls with hibernation so
> far, so this change is potentially risky.
Hi,
this patch can be dropped. I added it because I found in certain
devices, entering the hibernation flow and the subsequent ad hoc
reattaching of the USB subsystem to store the hibernation image can
cause these devices to turn on their vibration motor and leave it
stuck until hibernation completes (here, I assume the underlying cause
is the device briefly vibrates when initializing, but due to absent
initialization, it ends up stuck in that state).
So it is a bug fix. In any case, the commit message should state as
much if it is kept.
Antheas
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > kernel/power/hibernate.c | 29 +++++++++++++++++++++++++++--
> > 1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> > index af8d07bafe02..85a5ca8f6537 100644
> > --- a/kernel/power/hibernate.c
> > +++ b/kernel/power/hibernate.c
> > @@ -787,7 +787,11 @@ static int load_image_and_restore(void)
> > */
> > int hibernate(void)
> > {
> > +#ifdef CONFIG_SUSPEND
> > + standby_state_t previous_standby;
> > +#endif
> > bool snapshot_test = false;
> > + bool powered_down = false;
> > unsigned int sleep_flags;
> > int error;
> >
> > @@ -815,6 +819,13 @@ int hibernate(void)
> > }
> >
> > pr_info("hibernation entry\n");
> > +
> > +#if CONFIG_SUSPEND
> > + /* Enter the standby screen off state in case userspace has not. */
> > + previous_standby = pm_standby_get_state();
> > + pm_standby_transition(PM_STANDBY_INACTIVE);
> > +#endif
> > +
> > pm_prepare_console();
> > error = pm_notifier_call_chain_robust(PM_HIBERNATION_PREPARE, PM_POST_HIBERNATION);
> > if (error)
> > @@ -867,10 +878,12 @@ int hibernate(void)
> > error = swsusp_write(flags);
> > swsusp_free();
> > if (!error) {
> > - if (hibernation_mode == HIBERNATION_TEST_RESUME)
> > + if (hibernation_mode == HIBERNATION_TEST_RESUME) {
> > snapshot_test = true;
> > - else
> > + } else {
> > + powered_down = true;
> > power_down();
> > + }
> > }
> > in_suspend = 0;
> > pm_restore_gfp_mask();
> > @@ -897,6 +910,18 @@ int hibernate(void)
> > Notify:
> > pm_notifier_call_chain(PM_POST_HIBERNATION);
> > Restore:
> > +#if CONFIG_SUSPEND
> > + /*
> > + * If we resumed from S5, we are in the active standby state. However,
> > + * the kernel restored a stale value. Sync it. Otherwise, in e.g., the
> > + * case of a failed hibernation, transition to the previous value.
> > + */
> > + if (powered_down)
> > + pm_standby_set_state(PM_STANDBY_ACTIVE);
> > + else
> > + pm_standby_transition(previous_standby);
> > +#endif
> > +
> > pm_restore_console();
> > hibernate_release();
> > Unlock:
> > --
> > 2.52.0
> >
> >
> >
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [RFC v1 8/8] PM: standby: Add sysfs attribute for runtime standby transitions
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (6 preceding siblings ...)
2025-12-26 10:26 ` [RFC v1 7/8] PM: hibernate: Enter s2idle sleep state before hibernation Antheas Kapenekakis
@ 2025-12-26 10:26 ` Antheas Kapenekakis
2026-01-12 20:33 ` [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (2 subsequent siblings)
10 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2025-12-26 10:26 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, lkml, mccann, rafael, richard, sebastian.reichel,
superm1, systemd-devel, xaver.hugl
Add a sysfs attribute to allow informing the kernel about the current
standby state of the device depending on user involvement, those being:
"active", "inactive", "sleep", and "resume" (in "sleep" but preparing
for presenting to the user faster).
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
kernel/power/main.c | 84 ++++++++++++++++++++++++++++++++++++++++++++
kernel/power/power.h | 1 +
2 files changed, 85 insertions(+)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 03b2c5495c77..30494be41557 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -830,6 +830,89 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
power_attr(state);
+#ifdef CONFIG_SUSPEND
+/*
+ * standby - control system s2idle standby state.
+ *
+ * show() returns available standby states, which may be "active", "screen_off",
+ * "sleep" and "resume" (still in sleep but preparing to present to user).
+ * See Documentation/admin-guide/pm/standby-states.rst for a description of
+ * what they mean.
+ *
+ * store() accepts one of those strings and initiates a transition to that
+ * standby state.
+ *
+ * For backwards compatibility, when the system suspends, it first enters the
+ * state "sleep", regardless of what was written into store() and then during
+ * resume restores the previous value.
+ */
+static ssize_t standby_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ unsigned int sleep_flags;
+ standby_state_t i, curr;
+ char *s = buf;
+
+ sleep_flags = lock_system_sleep();
+ pm_standby_refresh_states();
+ curr = pm_standby_get_state();
+ unlock_system_sleep(sleep_flags);
+
+ if (curr < 0)
+ return -EBUSY;
+
+ for (i = PM_STANDBY_MIN; i < PM_STANDBY_MAX; i++)
+ if (standby_states[i])
+ s += sprintf(s, curr == i ? "[%s] " : "%s ", standby_states[i]);
+
+ if (s != buf)
+ /* convert the last space to a newline */
+ *(s - 1) = '\n';
+ return (s - buf);
+}
+
+static standby_state_t decode_standby_state(const char *buf, size_t n)
+{
+ standby_state_t state;
+ char *p;
+ int len;
+
+ p = memchr(buf, '\n', n);
+ len = p ? p - buf : n;
+
+ for (state = PM_STANDBY_MIN; state < PM_STANDBY_MAX; state++) {
+ const char *label = standby_states[state];
+
+ if (label && len == strlen(label) && !strncmp(buf, label, len))
+ return state;
+ }
+
+ return PM_STANDBY_MAX;
+}
+
+static ssize_t standby_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ unsigned int sleep_flags;
+ standby_state_t state;
+ int error;
+
+ sleep_flags = lock_system_sleep();
+ pm_standby_refresh_states();
+ state = decode_standby_state(buf, n);
+
+ if (state >= PM_STANDBY_MAX)
+ return -EINVAL;
+
+ error = pm_standby_transition(state);
+ unlock_system_sleep(sleep_flags);
+
+ return error ? error : n;
+}
+
+power_attr(standby);
+#endif
+
#ifdef CONFIG_PM_SLEEP
/*
* The 'wakeup_count' attribute, along with the functions defined in
@@ -1084,6 +1167,7 @@ static struct attribute * g[] = {
#ifdef CONFIG_SUSPEND
&mem_sleep_attr.attr,
&sync_on_suspend_attr.attr,
+ &standby_attr.attr,
#endif
#ifdef CONFIG_PM_AUTOSLEEP
&autosleep_attr.attr,
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 75b63843886e..2327a1ce2b05 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -216,6 +216,7 @@ extern void swsusp_show_speed(ktime_t, ktime_t, unsigned int, char *);
extern const char * const pm_labels[];
extern const char *pm_states[];
extern const char *mem_sleep_states[];
+extern const char *standby_states[];
extern int suspend_devices_and_enter(suspend_state_t state);
#else /* !CONFIG_SUSPEND */
--
2.52.0
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (7 preceding siblings ...)
2025-12-26 10:26 ` [RFC v1 8/8] PM: standby: Add sysfs attribute for runtime standby transitions Antheas Kapenekakis
@ 2026-01-12 20:33 ` Antheas Kapenekakis
2026-01-13 9:48 ` Dmitry Osipenko
2026-02-27 14:59 ` Antheas Kapenekakis
2026-03-13 19:36 ` Rafael J. Wysocki
10 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-01-12 20:33 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl
On Fri, 26 Dec 2025 at 12:27, Antheas Kapenekakis <lkml@antheas.dev> 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.
>
> snip
>
> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> --
> 2.52.0
>
Happy new year everyone
Small bump on this as all of us are starting to get back from holidays
I still have to bump an asus series before I get back to this. I would
appreciate some feedback in the interim.
I think targeting 6.20/7.0? is unrealistic so there is no rush from my side
Antheas
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-01-12 20:33 ` [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
@ 2026-01-13 9:48 ` Dmitry Osipenko
2026-01-13 10:11 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Dmitry Osipenko @ 2026-01-13 9:48 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl
Hello,
On 1/12/26 23:33, Antheas Kapenekakis wrote:
> On Fri, 26 Dec 2025 at 12:27, Antheas Kapenekakis <lkml@antheas.dev> 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.
>>
>> snip
>>
>> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
>> --
>> 2.52.0
>>
>
> Happy new year everyone
>
> Small bump on this as all of us are starting to get back from holidays
>
> I still have to bump an asus series before I get back to this. I would
> appreciate some feedback in the interim.
>
> I think targeting 6.20/7.0? is unrealistic so there is no rush from my side
>
> Antheas
Thanks a lot for sending these patches! I briefly looked through them
last week and will make another iteration soon.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-01-13 9:48 ` Dmitry Osipenko
@ 2026-01-13 10:11 ` Antheas Kapenekakis
2026-01-14 23:07 ` Dmitry Osipenko
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-01-13 10:11 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl
On Tue, 13 Jan 2026 at 11:50, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> Hello,
>
> On 1/12/26 23:33, Antheas Kapenekakis wrote:
> > On Fri, 26 Dec 2025 at 12:27, Antheas Kapenekakis <lkml@antheas.dev> 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.
> >>
> >> snip
> >>
> >> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> >> --
> >> 2.52.0
> >>
> >
> > Happy new year everyone
> >
> > Small bump on this as all of us are starting to get back from holidays
> >
> > I still have to bump an asus series before I get back to this. I would
> > appreciate some feedback in the interim.
> >
> > I think targeting 6.20/7.0? is unrealistic so there is no rush from my side
> >
> > Antheas
>
> Thanks a lot for sending these patches! I briefly looked through them
> last week and will make another iteration soon.
Hi Dmitry,
can you expand a bit on your use-case/KPIs/timeline for your series?
Is it handhelds/laptops or what is the intended use-case?
[2] before the rewrite had been tested on most handheld makes and SKUs
(over 70 models) and laptop manufacturers and it performs as expected.
As it is multiple months of research I'd like to get some credit for it.
Happy to collaborate in any case, especially if you will log hours on
this and can push a variant through faster. I am not sure if starting
from scratch is worthwhile for either of us
Best,
Antheas
> --
> Best regards,
> Dmitry
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-01-13 10:11 ` Antheas Kapenekakis
@ 2026-01-14 23:07 ` Dmitry Osipenko
2026-01-15 7:49 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Dmitry Osipenko @ 2026-01-14 23:07 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl, John Schoenick
On 1/13/26 13:11, Antheas Kapenekakis wrote:
> On Tue, 13 Jan 2026 at 11:50, Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>>
>> Hello,
>>
>> On 1/12/26 23:33, Antheas Kapenekakis wrote:
>>> On Fri, 26 Dec 2025 at 12:27, Antheas Kapenekakis <lkml@antheas.dev> 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.
>>>>
>>>> snip
>>>>
>>>> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
>>>> --
>>>> 2.52.0
>>>>
>>>
>>> Happy new year everyone
>>>
>>> Small bump on this as all of us are starting to get back from holidays
>>>
>>> I still have to bump an asus series before I get back to this. I would
>>> appreciate some feedback in the interim.
>>>
>>> I think targeting 6.20/7.0? is unrealistic so there is no rush from my side
>>>
>>> Antheas
>>
>> Thanks a lot for sending these patches! I briefly looked through them
>> last week and will make another iteration soon.
>
> Hi Dmitry,
> can you expand a bit on your use-case/KPIs/timeline for your series?
>
> Is it handhelds/laptops or what is the intended use-case?
>
> [2] before the rewrite had been tested on most handheld makes and SKUs
> (over 70 models) and laptop manufacturers and it performs as expected.
> As it is multiple months of research I'd like to get some credit for it.
>
> Happy to collaborate in any case, especially if you will log hours on
> this and can push a variant through faster. I am not sure if starting
> from scratch is worthwhile for either of us
The primary goal is to support screen-off DSM for a power-efficient
background games downloading [1] and further resume-to-dark on Steam
Deck and other handhelds. There is no strict timeline, usual "sooner the
better". Downstreams will use customized WIP solution till upstream will
get necessary generic interfaces.
[1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
A common approach for upstreaming is to divide problem into smaller
manageable parts. That's what I'm planning to focus on now to see if we
can start easy with a minimal changes.
Please don't worry about the credit. You did a significant ground work
that is well recognized by now. Thanks a lot for your efforts and help.
Starting from scratch of course won't be a good approach with all the
broad testing you've done.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-01-14 23:07 ` Dmitry Osipenko
@ 2026-01-15 7:49 ` Antheas Kapenekakis
2026-03-16 19:02 ` Dmitry Osipenko
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-01-15 7:49 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl, John Schoenick
On Thu, 15 Jan 2026 at 01:07, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> On 1/13/26 13:11, Antheas Kapenekakis wrote:
> > <snip>
Hi Dmitry,
let me go inline.
> The primary goal is to support screen-off DSM for a power-efficient
> background games downloading [1] and further resume-to-dark on Steam
> Deck and other handhelds. There is no strict timeline, usual "sooner the
> better". Downstreams will use customized WIP solution till upstream will
> get necessary generic interfaces.
>
> [1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
Ok, this makes things clearer. I had done some testing to see the
viability of such approach.
One big problem [1] had was that the compression algorithm that Steam
used was very CPU intensive. However, it was announced that that
changed, which makes low power downloads more viable.
However, even so, I do not think the sleep DSM is designed for
prolonged background use and certain devices might overheat.
Specifically, I think the Go S disables its fan while in that DSM.
Looking back to what Windows does, it only uses the Sleep state to do
periodic polling, and if there are updates it transitions to display
off.
This is a fair approach for [1]. For example, device wakes up every
two hours while connected to a charger, stays on sleep state, checks
for updates, and if there are any and conditions are met, transitions
to display off and starts downloading.
However, this means you do not get a smaller tdp limit. Given you
control the unfrozen userspace in that state though, such a limit does
not help either. The device will use what it needs to for downloads.
This makes the SD 5W low power mode puzzling, as it means downloads
will potentially take longer and I would be punished as a user for
using that mode. Instead, Steam should be optimized to use less than
5W or perhaps 10W when downloading from gigabit in some way.
Two more considerations in this case are that a lot of devices will
turn off their controllers when entering display off. And the rest
when entering sleep. This is good because when you are in dark resume,
the RGB of the device has turned off. But for [1] it is problematic
because it assumes the controller works and is what is used to wake
the device so the mode is broken. For Legion, Sleep is used to turn
off the controller, and for other devices Sleep Entry/Exit. New in ROG
Xbox Ally devices is that the controller no longer turns off, but it
is muted.
The other consideration is that three additional patches are needed
for ROG Ally devices to work correctly with this series, 2 cleanup
commits and 1 small delay. But after that it should be drop in. I
cannot comment on the new hid drivers for Asus and Legion that are
currently being developed. Particularly, hid-legion-go(?) has a
reset_resume() cb where it should have used resume? Or not anything?
The legion controllers save os mode until they disconnect, which they
do with this series, so the driver would always re-initialize on
wake-up.
> A common approach for upstreaming is to divide problem into smaller
> manageable parts. That's what I'm planning to focus on now to see if we
> can start easy with a minimal changes.
Sure. One potential approach for this is this series, where the first
part does the plumbing and the second part the exposing. They can be
merged independently.
I also made sure to address Rafael's comments, so the ABI of this
series is completely independent of ACPI, S0ix or whether the device
has a display. I also removed all references to Intel, AMD specific
power envelope terminology. Moreover, most of the logic now resides in
suspend.c and the hooks are in platform_ calls, so it can be
implemented for other platforms easily.
However, the first part of this series does some refactorings which
assume a favorable outcome. If we do not want to assume that, a
simpler initial series would just move the MS/display on/off DSMs to
.begin() in s2idle.c. If you think that would be easier to merge, you
are welcome to start with that. Then this series would be refactored
on top and merged as a single unit. Keep in mind the ROG Ally conflict
would also arise in this case as well.
> Please don't worry about the credit. You did a significant ground work
> that is well recognized by now. Thanks a lot for your efforts and help.
> Starting from scratch of course won't be a good approach with all the
> broad testing you've done.
Great. Sounds good to me.
Antheas
> --
> Best regards,
> Dmitry
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-01-15 7:49 ` Antheas Kapenekakis
@ 2026-03-16 19:02 ` Dmitry Osipenko
2026-03-16 19:33 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Dmitry Osipenko @ 2026-03-16 19:02 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl, John Schoenick
Hi Antheas,
On 1/15/26 10:49, Antheas Kapenekakis wrote:
> On Thu, 15 Jan 2026 at 01:07, Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>>
>> On 1/13/26 13:11, Antheas Kapenekakis wrote:
>>> <snip>
>
> Hi Dmitry,
> let me go inline.
>
>> The primary goal is to support screen-off DSM for a power-efficient
>> background games downloading [1] and further resume-to-dark on Steam
>> Deck and other handhelds. There is no strict timeline, usual "sooner the
>> better". Downstreams will use customized WIP solution till upstream will
>> get necessary generic interfaces.
>>
>> [1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
>
> Ok, this makes things clearer. I had done some testing to see the
> viability of such approach.
>
> One big problem [1] had was that the compression algorithm that Steam
> used was very CPU intensive. However, it was announced that that
> changed, which makes low power downloads more viable.
>
> However, even so, I do not think the sleep DSM is designed for
> prolonged background use and certain devices might overheat.
> Specifically, I think the Go S disables its fan while in that DSM.
> Looking back to what Windows does, it only uses the Sleep state to do
> periodic polling, and if there are updates it transitions to display
> off.
>
> This is a fair approach for [1]. For example, device wakes up every
> two hours while connected to a charger, stays on sleep state, checks
> for updates, and if there are any and conditions are met, transitions
> to display off and starts downloading.
>
> However, this means you do not get a smaller tdp limit. Given you
> control the unfrozen userspace in that state though, such a limit does
> not help either. The device will use what it needs to for downloads.
> This makes the SD 5W low power mode puzzling, as it means downloads
> will potentially take longer and I would be punished as a user for
> using that mode. Instead, Steam should be optimized to use less than
> 5W or perhaps 10W when downloading from gigabit in some way.
>
> Two more considerations in this case are that a lot of devices will
> turn off their controllers when entering display off. And the rest
> when entering sleep. This is good because when you are in dark resume,
> the RGB of the device has turned off. But for [1] it is problematic
> because it assumes the controller works and is what is used to wake
> the device so the mode is broken. For Legion, Sleep is used to turn
> off the controller, and for other devices Sleep Entry/Exit. New in ROG
> Xbox Ally devices is that the controller no longer turns off, but it
> is muted.
>
> The other consideration is that three additional patches are needed
> for ROG Ally devices to work correctly with this series, 2 cleanup
> commits and 1 small delay. But after that it should be drop in. I
> cannot comment on the new hid drivers for Asus and Legion that are
> currently being developed. Particularly, hid-legion-go(?) has a
> reset_resume() cb where it should have used resume? Or not anything?
> The legion controllers save os mode until they disconnect, which they
> do with this series, so the driver would always re-initialize on
> wake-up.
My rough understanding that a firmware/BIOS update may be needed for
some devices to leverage DSM in regards to power consumption
improvement. Could be true that practically it may not improve much,
will see. Even if not all current devices will benefit from the
screen-off DSM, it may differ for a later generations.
>> A common approach for upstreaming is to divide problem into smaller
>> manageable parts. That's what I'm planning to focus on now to see if we
>> can start easy with a minimal changes.
>
> Sure. One potential approach for this is this series, where the first
> part does the plumbing and the second part the exposing. They can be
> merged independently.
>
> I also made sure to address Rafael's comments, so the ABI of this
> series is completely independent of ACPI, S0ix or whether the device
> has a display. I also removed all references to Intel, AMD specific
> power envelope terminology. Moreover, most of the logic now resides in
> suspend.c and the hooks are in platform_ calls, so it can be
> implemented for other platforms easily.
>
> However, the first part of this series does some refactorings which
> assume a favorable outcome. If we do not want to assume that, a
> simpler initial series would just move the MS/display on/off DSMs to
> .begin() in s2idle.c. If you think that would be easier to merge, you
> are welcome to start with that. Then this series would be refactored
> on top and merged as a single unit. Keep in mind the ROG Ally conflict
> would also arise in this case as well.
>
>> Please don't worry about the credit. You did a significant ground work
>> that is well recognized by now. Thanks a lot for your efforts and help.
>> Starting from scratch of course won't be a good approach with all the
>> broad testing you've done.
>
> Great. Sounds good to me.
I'm taking latest version of your patches and will update them in
accordance to the review from Rafael.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-16 19:02 ` Dmitry Osipenko
@ 2026-03-16 19:33 ` Antheas Kapenekakis
2026-03-16 19:36 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 19:33 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl, John Schoenick
On Mon, 16 Mar 2026 at 20:03, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> Hi Antheas,
>
> On 1/15/26 10:49, Antheas Kapenekakis wrote:
> > On Thu, 15 Jan 2026 at 01:07, Dmitry Osipenko
> > <dmitry.osipenko@collabora.com> wrote:
> >>
> >> On 1/13/26 13:11, Antheas Kapenekakis wrote:
> >>> <snip>
> >
> > Hi Dmitry,
> > let me go inline.
> >
> >> The primary goal is to support screen-off DSM for a power-efficient
> >> background games downloading [1] and further resume-to-dark on Steam
> >> Deck and other handhelds. There is no strict timeline, usual "sooner the
> >> better". Downstreams will use customized WIP solution till upstream will
> >> get necessary generic interfaces.
> >>
> >> [1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
> >
> > Ok, this makes things clearer. I had done some testing to see the
> > viability of such approach.
> >
> > One big problem [1] had was that the compression algorithm that Steam
> > used was very CPU intensive. However, it was announced that that
> > changed, which makes low power downloads more viable.
> >
> > However, even so, I do not think the sleep DSM is designed for
> > prolonged background use and certain devices might overheat.
> > Specifically, I think the Go S disables its fan while in that DSM.
> > Looking back to what Windows does, it only uses the Sleep state to do
> > periodic polling, and if there are updates it transitions to display
> > off.
> >
> > This is a fair approach for [1]. For example, device wakes up every
> > two hours while connected to a charger, stays on sleep state, checks
> > for updates, and if there are any and conditions are met, transitions
> > to display off and starts downloading.
> >
> > However, this means you do not get a smaller tdp limit. Given you
> > control the unfrozen userspace in that state though, such a limit does
> > not help either. The device will use what it needs to for downloads.
> > This makes the SD 5W low power mode puzzling, as it means downloads
> > will potentially take longer and I would be punished as a user for
> > using that mode. Instead, Steam should be optimized to use less than
> > 5W or perhaps 10W when downloading from gigabit in some way.
> >
> > Two more considerations in this case are that a lot of devices will
> > turn off their controllers when entering display off. And the rest
> > when entering sleep. This is good because when you are in dark resume,
> > the RGB of the device has turned off. But for [1] it is problematic
> > because it assumes the controller works and is what is used to wake
> > the device so the mode is broken. For Legion, Sleep is used to turn
> > off the controller, and for other devices Sleep Entry/Exit. New in ROG
> > Xbox Ally devices is that the controller no longer turns off, but it
> > is muted.
> >
> > The other consideration is that three additional patches are needed
> > for ROG Ally devices to work correctly with this series, 2 cleanup
> > commits and 1 small delay. But after that it should be drop in. I
> > cannot comment on the new hid drivers for Asus and Legion that are
> > currently being developed. Particularly, hid-legion-go(?) has a
> > reset_resume() cb where it should have used resume? Or not anything?
> > The legion controllers save os mode until they disconnect, which they
> > do with this series, so the driver would always re-initialize on
> > wake-up.
>
> My rough understanding that a firmware/BIOS update may be needed for
> some devices to leverage DSM in regards to power consumption
> improvement. Could be true that practically it may not improve much,
> will see. Even if not all current devices will benefit from the
> screen-off DSM, it may differ for a later generations.
Hi Dmitry,
sorry, I have been busy the past few days. I read through Rafael's
comments, I will respond to them in the next 2-3 days.
Your understanding is correct. You will see 0 performance difference
with the screen off DSM. It is not supposed to affect the thermal
envelope. Turning off the screens of your laptop due to inactivity is
not supposed to affect the thermal envelope.
For devices that use the DSM to turn off their controller (~60%),
there might be a marginal <.5W improvement. The rest use the sleep
DSMs for that. Those do affect the thermal envelope. However, they are
not designed for prolonged CPU intensive tasks such as a SteamOS
download mode. This is the bigger concern. From my experience, I
expect the Go S to overheat.
The improvement because of turning off the controllers / RGB is
something that is needed for download mode in any case. And as my
previous comment suggests, lowering the thermal limit may not be
required / advantageous.
> >> A common approach for upstreaming is to divide problem into smaller
> >> manageable parts. That's what I'm planning to focus on now to see if we
> >> can start easy with a minimal changes.
> >
> > Sure. One potential approach for this is this series, where the first
> > part does the plumbing and the second part the exposing. They can be
> > merged independently.
> >
> > I also made sure to address Rafael's comments, so the ABI of this
> > series is completely independent of ACPI, S0ix or whether the device
> > has a display. I also removed all references to Intel, AMD specific
> > power envelope terminology. Moreover, most of the logic now resides in
> > suspend.c and the hooks are in platform_ calls, so it can be
> > implemented for other platforms easily.
> >
> > However, the first part of this series does some refactorings which
> > assume a favorable outcome. If we do not want to assume that, a
> > simpler initial series would just move the MS/display on/off DSMs to
> > .begin() in s2idle.c. If you think that would be easier to merge, you
> > are welcome to start with that. Then this series would be refactored
> > on top and merged as a single unit. Keep in mind the ROG Ally conflict
> > would also arise in this case as well.
> >
> >> Please don't worry about the credit. You did a significant ground work
> >> that is well recognized by now. Thanks a lot for your efforts and help.
> >> Starting from scratch of course won't be a good approach with all the
> >> broad testing you've done.
> >
> > Great. Sounds good to me.
>
> I'm taking latest version of your patches and will update them in
> accordance to the review from Rafael.
Rafael raised some good questions I need to respond to. Specifically,
the ABI is not yet decided, so the comments are not ready to address
yet.
Nonetheless, this series is ready to test with the current ABI.
Moreover, Rafael suggests for upstreaming to follow essentially what I
outlined. An initial series should move the DSMs to the beginning of
the suspend sequence, and the follow-up would implement the ABI.
I was planning to work on the first sub-series as a non-RFC after
responding to Rafael's comments. Let me know how you plan to proceed.
Best,
Antheas
> --
> Best regards,
> Dmitry
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-16 19:33 ` Antheas Kapenekakis
@ 2026-03-16 19:36 ` Antheas Kapenekakis
2026-03-17 11:04 ` Dmitry Osipenko
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 19:36 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl, John Schoenick
On Mon, 16 Mar 2026 at 20:33, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> On Mon, 16 Mar 2026 at 20:03, Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> >
> > Hi Antheas,
> >
> > On 1/15/26 10:49, Antheas Kapenekakis wrote:
> > > On Thu, 15 Jan 2026 at 01:07, Dmitry Osipenko
> > > <dmitry.osipenko@collabora.com> wrote:
> > >>
> > >> On 1/13/26 13:11, Antheas Kapenekakis wrote:
> > >>> <snip>
> > >
> > > Hi Dmitry,
> > > let me go inline.
> > >
> > >> The primary goal is to support screen-off DSM for a power-efficient
> > >> background games downloading [1] and further resume-to-dark on Steam
> > >> Deck and other handhelds. There is no strict timeline, usual "sooner the
> > >> better". Downstreams will use customized WIP solution till upstream will
> > >> get necessary generic interfaces.
> > >>
> > >> [1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
> > >
> > > Ok, this makes things clearer. I had done some testing to see the
> > > viability of such approach.
> > >
> > > One big problem [1] had was that the compression algorithm that Steam
> > > used was very CPU intensive. However, it was announced that that
> > > changed, which makes low power downloads more viable.
> > >
> > > However, even so, I do not think the sleep DSM is designed for
> > > prolonged background use and certain devices might overheat.
> > > Specifically, I think the Go S disables its fan while in that DSM.
> > > Looking back to what Windows does, it only uses the Sleep state to do
> > > periodic polling, and if there are updates it transitions to display
> > > off.
> > >
> > > This is a fair approach for [1]. For example, device wakes up every
> > > two hours while connected to a charger, stays on sleep state, checks
> > > for updates, and if there are any and conditions are met, transitions
> > > to display off and starts downloading.
> > >
> > > However, this means you do not get a smaller tdp limit. Given you
> > > control the unfrozen userspace in that state though, such a limit does
> > > not help either. The device will use what it needs to for downloads.
> > > This makes the SD 5W low power mode puzzling, as it means downloads
> > > will potentially take longer and I would be punished as a user for
> > > using that mode. Instead, Steam should be optimized to use less than
> > > 5W or perhaps 10W when downloading from gigabit in some way.
> > >
> > > Two more considerations in this case are that a lot of devices will
> > > turn off their controllers when entering display off. And the rest
> > > when entering sleep. This is good because when you are in dark resume,
> > > the RGB of the device has turned off. But for [1] it is problematic
> > > because it assumes the controller works and is what is used to wake
> > > the device so the mode is broken. For Legion, Sleep is used to turn
> > > off the controller, and for other devices Sleep Entry/Exit. New in ROG
> > > Xbox Ally devices is that the controller no longer turns off, but it
> > > is muted.
> > >
> > > The other consideration is that three additional patches are needed
> > > for ROG Ally devices to work correctly with this series, 2 cleanup
> > > commits and 1 small delay. But after that it should be drop in. I
> > > cannot comment on the new hid drivers for Asus and Legion that are
> > > currently being developed. Particularly, hid-legion-go(?) has a
> > > reset_resume() cb where it should have used resume? Or not anything?
> > > The legion controllers save os mode until they disconnect, which they
> > > do with this series, so the driver would always re-initialize on
> > > wake-up.
> >
> > My rough understanding that a firmware/BIOS update may be needed for
> > some devices to leverage DSM in regards to power consumption
> > improvement. Could be true that practically it may not improve much,
> > will see. Even if not all current devices will benefit from the
> > screen-off DSM, it may differ for a later generations.
>
> Hi Dmitry,
> sorry, I have been busy the past few days. I read through Rafael's
> comments, I will respond to them in the next 2-3 days.
>
> Your understanding is correct. You will see 0 performance difference
> with the screen off DSM. It is not supposed to affect the thermal
> envelope. Turning off the screens of your laptop due to inactivity is
> not supposed to affect the thermal envelope.
>
> For devices that use the DSM to turn off their controller (~60%),
> there might be a marginal <.5W improvement. The rest use the sleep
> DSMs for that. Those do affect the thermal envelope. However, they are
> not designed for prolonged CPU intensive tasks such as a SteamOS
> download mode. This is the bigger concern. From my experience, I
> expect the Go S to overheat.
>
> The improvement because of turning off the controllers / RGB is
> something that is needed for download mode in any case. And as my
> previous comment suggests, lowering the thermal limit may not be
> required / advantageous.
Here, the sleep dsms are also important, because of their broad
effects to power light / thermal envelope. As they can be used for
brief wake / update checks. For battery powered devices, perhaps these
are not important (excl. hibernation checks), but for desktop consoles
it is expected functionality.
> > >> A common approach for upstreaming is to divide problem into smaller
> > >> manageable parts. That's what I'm planning to focus on now to see if we
> > >> can start easy with a minimal changes.
> > >
> > > Sure. One potential approach for this is this series, where the first
> > > part does the plumbing and the second part the exposing. They can be
> > > merged independently.
> > >
> > > I also made sure to address Rafael's comments, so the ABI of this
> > > series is completely independent of ACPI, S0ix or whether the device
> > > has a display. I also removed all references to Intel, AMD specific
> > > power envelope terminology. Moreover, most of the logic now resides in
> > > suspend.c and the hooks are in platform_ calls, so it can be
> > > implemented for other platforms easily.
> > >
> > > However, the first part of this series does some refactorings which
> > > assume a favorable outcome. If we do not want to assume that, a
> > > simpler initial series would just move the MS/display on/off DSMs to
> > > .begin() in s2idle.c. If you think that would be easier to merge, you
> > > are welcome to start with that. Then this series would be refactored
> > > on top and merged as a single unit. Keep in mind the ROG Ally conflict
> > > would also arise in this case as well.
> > >
> > >> Please don't worry about the credit. You did a significant ground work
> > >> that is well recognized by now. Thanks a lot for your efforts and help.
> > >> Starting from scratch of course won't be a good approach with all the
> > >> broad testing you've done.
> > >
> > > Great. Sounds good to me.
> >
> > I'm taking latest version of your patches and will update them in
> > accordance to the review from Rafael.
>
> Rafael raised some good questions I need to respond to. Specifically,
> the ABI is not yet decided, so the comments are not ready to address
> yet.
>
> Nonetheless, this series is ready to test with the current ABI.
>
> Moreover, Rafael suggests for upstreaming to follow essentially what I
> outlined. An initial series should move the DSMs to the beginning of
> the suspend sequence, and the follow-up would implement the ABI.
>
> I was planning to work on the first sub-series as a non-RFC after
> responding to Rafael's comments. Let me know how you plan to proceed.
>
> Best,
> Antheas
>
> > --
> > Best regards,
> > Dmitry
> >
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-16 19:36 ` Antheas Kapenekakis
@ 2026-03-17 11:04 ` Dmitry Osipenko
0 siblings, 0 replies; 41+ messages in thread
From: Dmitry Osipenko @ 2026-03-17 11:04 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl, John Schoenick
On 3/16/26 22:36, Antheas Kapenekakis wrote:
> On Mon, 16 Mar 2026 at 20:33, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>>
>> On Mon, 16 Mar 2026 at 20:03, Dmitry Osipenko
>> <dmitry.osipenko@collabora.com> wrote:
>>>
>>> Hi Antheas,
>>>
>>> On 1/15/26 10:49, Antheas Kapenekakis wrote:
>>>> On Thu, 15 Jan 2026 at 01:07, Dmitry Osipenko
>>>> <dmitry.osipenko@collabora.com> wrote:
>>>>>
>>>>> On 1/13/26 13:11, Antheas Kapenekakis wrote:
>>>>>> <snip>
>>>>
>>>> Hi Dmitry,
>>>> let me go inline.
>>>>
>>>>> The primary goal is to support screen-off DSM for a power-efficient
>>>>> background games downloading [1] and further resume-to-dark on Steam
>>>>> Deck and other handhelds. There is no strict timeline, usual "sooner the
>>>>> better". Downstreams will use customized WIP solution till upstream will
>>>>> get necessary generic interfaces.
>>>>>
>>>>> [1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
>>>>
>>>> Ok, this makes things clearer. I had done some testing to see the
>>>> viability of such approach.
>>>>
>>>> One big problem [1] had was that the compression algorithm that Steam
>>>> used was very CPU intensive. However, it was announced that that
>>>> changed, which makes low power downloads more viable.
>>>>
>>>> However, even so, I do not think the sleep DSM is designed for
>>>> prolonged background use and certain devices might overheat.
>>>> Specifically, I think the Go S disables its fan while in that DSM.
>>>> Looking back to what Windows does, it only uses the Sleep state to do
>>>> periodic polling, and if there are updates it transitions to display
>>>> off.
>>>>
>>>> This is a fair approach for [1]. For example, device wakes up every
>>>> two hours while connected to a charger, stays on sleep state, checks
>>>> for updates, and if there are any and conditions are met, transitions
>>>> to display off and starts downloading.
>>>>
>>>> However, this means you do not get a smaller tdp limit. Given you
>>>> control the unfrozen userspace in that state though, such a limit does
>>>> not help either. The device will use what it needs to for downloads.
>>>> This makes the SD 5W low power mode puzzling, as it means downloads
>>>> will potentially take longer and I would be punished as a user for
>>>> using that mode. Instead, Steam should be optimized to use less than
>>>> 5W or perhaps 10W when downloading from gigabit in some way.
>>>>
>>>> Two more considerations in this case are that a lot of devices will
>>>> turn off their controllers when entering display off. And the rest
>>>> when entering sleep. This is good because when you are in dark resume,
>>>> the RGB of the device has turned off. But for [1] it is problematic
>>>> because it assumes the controller works and is what is used to wake
>>>> the device so the mode is broken. For Legion, Sleep is used to turn
>>>> off the controller, and for other devices Sleep Entry/Exit. New in ROG
>>>> Xbox Ally devices is that the controller no longer turns off, but it
>>>> is muted.
>>>>
>>>> The other consideration is that three additional patches are needed
>>>> for ROG Ally devices to work correctly with this series, 2 cleanup
>>>> commits and 1 small delay. But after that it should be drop in. I
>>>> cannot comment on the new hid drivers for Asus and Legion that are
>>>> currently being developed. Particularly, hid-legion-go(?) has a
>>>> reset_resume() cb where it should have used resume? Or not anything?
>>>> The legion controllers save os mode until they disconnect, which they
>>>> do with this series, so the driver would always re-initialize on
>>>> wake-up.
>>>
>>> My rough understanding that a firmware/BIOS update may be needed for
>>> some devices to leverage DSM in regards to power consumption
>>> improvement. Could be true that practically it may not improve much,
>>> will see. Even if not all current devices will benefit from the
>>> screen-off DSM, it may differ for a later generations.
>>
>> Hi Dmitry,
>> sorry, I have been busy the past few days. I read through Rafael's
>> comments, I will respond to them in the next 2-3 days.
>>
>> Your understanding is correct. You will see 0 performance difference
>> with the screen off DSM. It is not supposed to affect the thermal
>> envelope. Turning off the screens of your laptop due to inactivity is
>> not supposed to affect the thermal envelope.
>>
>> For devices that use the DSM to turn off their controller (~60%),
>> there might be a marginal <.5W improvement. The rest use the sleep
>> DSMs for that. Those do affect the thermal envelope. However, they are
>> not designed for prolonged CPU intensive tasks such as a SteamOS
>> download mode. This is the bigger concern. From my experience, I
>> expect the Go S to overheat.
>>
>> The improvement because of turning off the controllers / RGB is
>> something that is needed for download mode in any case. And as my
>> previous comment suggests, lowering the thermal limit may not be
>> required / advantageous.
>
> Here, the sleep dsms are also important, because of their broad
> effects to power light / thermal envelope. As they can be used for
> brief wake / update checks. For battery powered devices, perhaps these
> are not important (excl. hibernation checks), but for desktop consoles
> it is expected functionality.
>
>>>>> A common approach for upstreaming is to divide problem into smaller
>>>>> manageable parts. That's what I'm planning to focus on now to see if we
>>>>> can start easy with a minimal changes.
>>>>
>>>> Sure. One potential approach for this is this series, where the first
>>>> part does the plumbing and the second part the exposing. They can be
>>>> merged independently.
>>>>
>>>> I also made sure to address Rafael's comments, so the ABI of this
>>>> series is completely independent of ACPI, S0ix or whether the device
>>>> has a display. I also removed all references to Intel, AMD specific
>>>> power envelope terminology. Moreover, most of the logic now resides in
>>>> suspend.c and the hooks are in platform_ calls, so it can be
>>>> implemented for other platforms easily.
>>>>
>>>> However, the first part of this series does some refactorings which
>>>> assume a favorable outcome. If we do not want to assume that, a
>>>> simpler initial series would just move the MS/display on/off DSMs to
>>>> .begin() in s2idle.c. If you think that would be easier to merge, you
>>>> are welcome to start with that. Then this series would be refactored
>>>> on top and merged as a single unit. Keep in mind the ROG Ally conflict
>>>> would also arise in this case as well.
>>>>
>>>>> Please don't worry about the credit. You did a significant ground work
>>>>> that is well recognized by now. Thanks a lot for your efforts and help.
>>>>> Starting from scratch of course won't be a good approach with all the
>>>>> broad testing you've done.
>>>>
>>>> Great. Sounds good to me.
>>>
>>> I'm taking latest version of your patches and will update them in
>>> accordance to the review from Rafael.
>>
>> Rafael raised some good questions I need to respond to. Specifically,
>> the ABI is not yet decided, so the comments are not ready to address
>> yet.
>>
>> Nonetheless, this series is ready to test with the current ABI.
>>
>> Moreover, Rafael suggests for upstreaming to follow essentially what I
>> outlined. An initial series should move the DSMs to the beginning of
>> the suspend sequence, and the follow-up would implement the ABI.
>>
>> I was planning to work on the first sub-series as a non-RFC after
>> responding to Rafael's comments. Let me know how you plan to proceed.
Please go on and make a v2. This version works well with my testing. Thanks!
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (8 preceding siblings ...)
2026-01-12 20:33 ` [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
@ 2026-02-27 14:59 ` Antheas Kapenekakis
2026-02-27 18:42 ` Rafael J. Wysocki
2026-03-13 19:36 ` Rafael J. Wysocki
10 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-02-27 14:59 UTC (permalink / raw)
To: dmitry.osipenko
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, rafael, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl
Hi everyone,
now that the kernel merge window is over, I will slowly get back to
cleaning this series up
I already have some feedback that I will address with V2.
Specifically, we found out that the resume DSM needs to always be
called and it merged with 7.0. So I will rebase on top of it, remove
the patch that added it, and rework the logic to always call resume
before sleep exit. I am not sure how I will tackle this or whether it
will involve reshaping the FSM states.
Then, there was a compilation warning reported by the kernel bot.
Afterwards, I reviewed the feedback in the Phoronix article. People
would like to have an option to turn this feature off, or perhaps
force it off. We could add a Y/n Kconfig for the sysfs patch
defaulting to Y that enables it, which will be the appropriate option
for consumer kernels. Or a kernel command line parameter so that users
do not need to produce their own kernel.
Finally, there is the issue of the Ally devices, which will need a
partial cleanup that needs to go through platform-x86 and hid core,
which would make this series touch 3 subsystems. I would tend towards
omitting it for V2 to keep a short(er) cc list, but I can produce it
for testing as an addendum.
I have my plate full for the next week, so if you would like for me to
consider some feedback, next week would be a good time to review this
series.
Best,
Antheas
On Fri, 26 Dec 2025 at 11:27, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> <snip>
> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> --
> 2.52.0
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-02-27 14:59 ` Antheas Kapenekakis
@ 2026-02-27 18:42 ` Rafael J. Wysocki
0 siblings, 0 replies; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-02-27 18:42 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, rafael, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, Feb 27, 2026 at 4:00 PM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> Hi everyone,
> now that the kernel merge window is over, I will slowly get back to
> cleaning this series up
>
> I already have some feedback that I will address with V2.
>
> Specifically, we found out that the resume DSM needs to always be
> called and it merged with 7.0. So I will rebase on top of it, remove
> the patch that added it, and rework the logic to always call resume
> before sleep exit. I am not sure how I will tackle this or whether it
> will involve reshaping the FSM states.
>
> Then, there was a compilation warning reported by the kernel bot.
>
> Afterwards, I reviewed the feedback in the Phoronix article. People
> would like to have an option to turn this feature off, or perhaps
> force it off. We could add a Y/n Kconfig for the sysfs patch
> defaulting to Y that enables it, which will be the appropriate option
> for consumer kernels. Or a kernel command line parameter so that users
> do not need to produce their own kernel.
>
> Finally, there is the issue of the Ally devices, which will need a
> partial cleanup that needs to go through platform-x86 and hid core,
> which would make this series touch 3 subsystems. I would tend towards
> omitting it for V2 to keep a short(er) cc list, but I can produce it
> for testing as an addendum.
>
> I have my plate full for the next week, so if you would like for me to
> consider some feedback, next week would be a good time to review this
> series.
I have some feedback already, but I'm not sure when I can get to it
realistically. I'm already starting to be oversubscribed for next
week, unfortunately.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2025-12-26 10:26 [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms Antheas Kapenekakis
` (9 preceding siblings ...)
2026-02-27 14:59 ` Antheas Kapenekakis
@ 2026-03-13 19:36 ` Rafael J. Wysocki
2026-03-16 19:52 ` Antheas Kapenekakis
10 siblings, 1 reply; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-03-13 19:36 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, rafael, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
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.
On Fri, Dec 26, 2025 at 11:27 AM Antheas Kapenekakis <lkml@antheas.dev> 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).
> 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).
> 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 ?
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-13 19:36 ` Rafael J. Wysocki
@ 2026-03-16 19:52 ` Antheas Kapenekakis
2026-03-17 11:56 ` Dmitry Osipenko
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-16 19:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dmitry.osipenko, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Fri, 13 Mar 2026 at 20:36, Rafael J. Wysocki <rafael@kernel.org> 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@antheas.dev> 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 ?
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-16 19:52 ` Antheas Kapenekakis
@ 2026-03-17 11:56 ` Dmitry Osipenko
2026-03-17 12:09 ` Rafael J. Wysocki
0 siblings, 1 reply; 41+ messages in thread
From: Dmitry Osipenko @ 2026-03-17 11:56 UTC (permalink / raw)
To: Antheas Kapenekakis, Rafael J. Wysocki
Cc: bob.beckett, bookeldor, hadess, jaap, kernel, lennart, linux-acpi,
linux-kernel, mccann, richard, sebastian.reichel, superm1,
systemd-devel, xaver.hugl
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.
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.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-17 11:56 ` Dmitry Osipenko
@ 2026-03-17 12:09 ` Rafael J. Wysocki
2026-03-17 15:13 ` Mario Limonciello
0 siblings, 1 reply; 41+ messages in thread
From: Rafael J. Wysocki @ 2026-03-17 12:09 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Antheas Kapenekakis, Rafael J. Wysocki, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> 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".
> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-17 12:09 ` Rafael J. Wysocki
@ 2026-03-17 15:13 ` Mario Limonciello
2026-03-19 12:35 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Mario Limonciello @ 2026-03-17 15:13 UTC (permalink / raw)
To: Rafael J. Wysocki, Dmitry Osipenko
Cc: Antheas Kapenekakis, bob.beckett, bookeldor, hadess, jaap, kernel,
lennart, linux-acpi, linux-kernel, mccann, richard,
sebastian.reichel, superm1, systemd-devel, xaver.hugl
On 3/17/26 07:09, Rafael J. Wysocki wrote:
> On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> 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.
There could be hooks for scheduler too in the future from this hint too
then.
>> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-17 15:13 ` Mario Limonciello
@ 2026-03-19 12:35 ` Antheas Kapenekakis
2026-03-20 20:41 ` Mario Limonciello (AMD) (kernel.org)
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-19 12:35 UTC (permalink / raw)
To: Mario Limonciello
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, superm1, systemd-devel, xaver.hugl
On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 3/17/26 07:09, Rafael J. Wysocki wrote:
> > On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
> > <dmitry.osipenko@collabora.com> 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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-19 12:35 ` Antheas Kapenekakis
@ 2026-03-20 20:41 ` Mario Limonciello (AMD) (kernel.org)
2026-03-21 13:46 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Mario Limonciello (AMD) (kernel.org) @ 2026-03-20 20:41 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, superm1, systemd-devel, xaver.hugl
On 3/19/2026 7:35 AM, Antheas Kapenekakis wrote:
> On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> On 3/17/26 07:09, Rafael J. Wysocki wrote:
>>> On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
>>> <dmitry.osipenko@collabora.com> 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 are certainly people using it, but it's more common in embedded
applications than traditional desktop distros.
It is not a perfect match to this concept, but definitely some parallels
can be drawn.
There are general things that might make sense if you know what the
foreground workload is or the display is off.
>
>> 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.
I don't know one way or the other. It would need to be prototyped to
see what it actually looked like. In the line of thinking Rafael
mentioned that platform profile was ACPI and grew to a class I would
generally just keep the design from pigeon holing too much on display
off. That's why I thought maybe foreground workload could potentially
work well.
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-20 20:41 ` Mario Limonciello (AMD) (kernel.org)
@ 2026-03-21 13:46 ` Antheas Kapenekakis
2026-03-21 13:52 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-21 13:46 UTC (permalink / raw)
To: Mario Limonciello (AMD) (kernel.org)
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, systemd-devel, xaver.hugl
On Fri, 20 Mar 2026 at 21:41, Mario Limonciello (AMD) (kernel.org)
<superm1@kernel.org> wrote:
>
>
>
> On 3/19/2026 7:35 AM, Antheas Kapenekakis wrote:
> > On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
> > <mario.limonciello@amd.com> wrote:
> >>
> >>
> >>
> >> On 3/17/26 07:09, Rafael J. Wysocki wrote:
> >>> On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
> >>> <dmitry.osipenko@collabora.com> 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 are certainly people using it, but it's more common in embedded
> applications than traditional desktop distros.
>
> It is not a perfect match to this concept, but definitely some parallels
> can be drawn.
>
> There are general things that might make sense if you know what the
> foreground workload is or the display is off.
Hm, yeah I guess so. I could see this ABI being also useful for
embedded devices to control their appearance. There's precedent with
e.g., charging_behaviour having dozens of device specific values,
where standard and longevity are the only ones used in laptops.
> >
> >> 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.
>
> I don't know one way or the other. It would need to be prototyped to
> see what it actually looked like. In the line of thinking Rafael
> mentioned that platform profile was ACPI and grew to a class I would
> generally just keep the design from pigeon holing too much on display
> off. That's why I thought maybe foreground workload could potentially
> work well.
To go back to Rafael's suggestion of not using transitions for the
ABI, it would be possible to push the transition logic down to the
s2idle code and introduce a generic handler for it. SInce arbitrary
transitions are possible under this spec, the top-level ABI
implementation need not consider it.
Since it is very similar to platform_profiles, it could also be
potentially added there as activity_hint to the current
platform_profiles implementation and mirror its conventions. This
would avoid introducing new scaffolding.
Then s2idle would register a platform profile handler without
profiles, and instead only implement activity hint. Existing x86
platform drivers could also trivially implement support for it as
well. Although for WMI, the existing hooks for s2idle for Windows
would handle most current drivers.
An implementation for this would consist of two stages. First, the
callbacks would be moved to the beginning so they can be tested
independently. Then, platform_profile would be extended to support
activity_hint with states {snooze, resuming, inactive, active}, and
finally, s2idle would implement the handler with transition logic to
make sure the callbacks get called correctly always, including when
userspace ignores the file, where the full transition would occur in
begin() and end().
The legacy /sys/firmware/acpi/{activity_hint, activity_hint_choices}
would mirror the current conventions, perhaps with a custom value as
well.
How does this approach sound?
Antheas
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-21 13:46 ` Antheas Kapenekakis
@ 2026-03-21 13:52 ` Antheas Kapenekakis
2026-03-21 18:43 ` Mario Limonciello
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-21 13:52 UTC (permalink / raw)
To: Mario Limonciello (AMD) (kernel.org)
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, systemd-devel, xaver.hugl
On Sat, 21 Mar 2026 at 14:46, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> On Fri, 20 Mar 2026 at 21:41, Mario Limonciello (AMD) (kernel.org)
> <superm1@kernel.org> wrote:
> >
> >
> >
> > On 3/19/2026 7:35 AM, Antheas Kapenekakis wrote:
> > > On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
> > > <mario.limonciello@amd.com> wrote:
> > >>
> > >>
> > >>
> > >> On 3/17/26 07:09, Rafael J. Wysocki wrote:
> > >>> On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
> > >>> <dmitry.osipenko@collabora.com> 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 are certainly people using it, but it's more common in embedded
> > applications than traditional desktop distros.
> >
> > It is not a perfect match to this concept, but definitely some parallels
> > can be drawn.
> >
> > There are general things that might make sense if you know what the
> > foreground workload is or the display is off.
>
> Hm, yeah I guess so. I could see this ABI being also useful for
> embedded devices to control their appearance. There's precedent with
> e.g., charging_behaviour having dozens of device specific values,
> where standard and longevity are the only ones used in laptops.
>
> > >
> > >> 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.
> >
> > I don't know one way or the other. It would need to be prototyped to
> > see what it actually looked like. In the line of thinking Rafael
> > mentioned that platform profile was ACPI and grew to a class I would
> > generally just keep the design from pigeon holing too much on display
> > off. That's why I thought maybe foreground workload could potentially
> > work well.
>
> To go back to Rafael's suggestion of not using transitions for the
> ABI, it would be possible to push the transition logic down to the
> s2idle code and introduce a generic handler for it. SInce arbitrary
> transitions are possible under this spec, the top-level ABI
> implementation need not consider it.
>
> Since it is very similar to platform_profiles, it could also be
> potentially added there as activity_hint to the current
> platform_profiles implementation and mirror its conventions. This
> would avoid introducing new scaffolding.
>
> Then s2idle would register a platform profile handler without
> profiles, and instead only implement activity hint. Existing x86
> platform drivers could also trivially implement support for it as
> well. Although for WMI, the existing hooks for s2idle for Windows
> would handle most current drivers.
>
> An implementation for this would consist of two stages. First, the
> callbacks would be moved to the beginning so they can be tested
> independently. Then, platform_profile would be extended to support
> activity_hint with states {snooze, resuming, inactive, active}, and
> finally, s2idle would implement the handler with transition logic to
> make sure the callbacks get called correctly always, including when
> userspace ignores the file, where the full transition would occur in
> begin() and end().
>
> The legacy /sys/firmware/acpi/{activity_hint, activity_hint_choices}
> would mirror the current conventions, perhaps with a custom value as
> well.
>
> How does this approach sound?
Perhaps re-using platform_profiles is not wise, after all the
boilerplate would be small and bolting on new hooks would be around
the same amount of code. New implementation would be better. How would
that approach sound like.
> Antheas
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-21 13:52 ` Antheas Kapenekakis
@ 2026-03-21 18:43 ` Mario Limonciello
2026-03-21 22:33 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Mario Limonciello @ 2026-03-21 18:43 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, systemd-devel, xaver.hugl
On 3/21/26 8:52 AM, Antheas Kapenekakis wrote:
> On Sat, 21 Mar 2026 at 14:46, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>>
>> On Fri, 20 Mar 2026 at 21:41, Mario Limonciello (AMD) (kernel.org)
>> <superm1@kernel.org> wrote:
>>>
>>>
>>>
>>> On 3/19/2026 7:35 AM, Antheas Kapenekakis wrote:
>>>> On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
>>>> <mario.limonciello@amd.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/17/26 07:09, Rafael J. Wysocki wrote:
>>>>>> On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
>>>>>> <dmitry.osipenko@collabora.com> 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 are certainly people using it, but it's more common in embedded
>>> applications than traditional desktop distros.
>>>
>>> It is not a perfect match to this concept, but definitely some parallels
>>> can be drawn.
>>>
>>> There are general things that might make sense if you know what the
>>> foreground workload is or the display is off.
>>
>> Hm, yeah I guess so. I could see this ABI being also useful for
>> embedded devices to control their appearance. There's precedent with
>> e.g., charging_behaviour having dozens of device specific values,
>> where standard and longevity are the only ones used in laptops.
>>
>>>>
>>>>> 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.
>>>
>>> I don't know one way or the other. It would need to be prototyped to
>>> see what it actually looked like. In the line of thinking Rafael
>>> mentioned that platform profile was ACPI and grew to a class I would
>>> generally just keep the design from pigeon holing too much on display
>>> off. That's why I thought maybe foreground workload could potentially
>>> work well.
>>
>> To go back to Rafael's suggestion of not using transitions for the
>> ABI, it would be possible to push the transition logic down to the
>> s2idle code and introduce a generic handler for it. SInce arbitrary
>> transitions are possible under this spec, the top-level ABI
>> implementation need not consider it.
>>
>> Since it is very similar to platform_profiles, it could also be
>> potentially added there as activity_hint to the current
>> platform_profiles implementation and mirror its conventions. This
>> would avoid introducing new scaffolding.
>>
>> Then s2idle would register a platform profile handler without
>> profiles, and instead only implement activity hint. Existing x86
>> platform drivers could also trivially implement support for it as
>> well. Although for WMI, the existing hooks for s2idle for Windows
>> would handle most current drivers.
>>
>> An implementation for this would consist of two stages. First, the
>> callbacks would be moved to the beginning so they can be tested
>> independently. Then, platform_profile would be extended to support
>> activity_hint with states {snooze, resuming, inactive, active}, and
>> finally, s2idle would implement the handler with transition logic to
>> make sure the callbacks get called correctly always, including when
>> userspace ignores the file, where the full transition would occur in
>> begin() and end().
>>
>> The legacy /sys/firmware/acpi/{activity_hint, activity_hint_choices}
>> would mirror the current conventions, perhaps with a custom value as
>> well.
>>
>> How does this approach sound?
>
> Perhaps re-using platform_profiles is not wise, after all the
> boilerplate would be small and bolting on new hooks would be around
> the same amount of code. New implementation would be better. How would
> that approach sound like.
>
>> Antheas
>
I really don't want our top level interface for this thing to end up in
/sys/firmware/acpi. The concept of system posture, or foreground
workload, or whatever we call it isn't an ACPI concept. It might have
direct implications for an ACPI implementation (IE the calling of this
_DSM) but there is no reason we can't have a non-ACPI implementation too
with the right knobs.
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-21 18:43 ` Mario Limonciello
@ 2026-03-21 22:33 ` Antheas Kapenekakis
2026-03-23 4:36 ` Mario Limonciello
0 siblings, 1 reply; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-21 22:33 UTC (permalink / raw)
To: Mario Limonciello
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, systemd-devel, xaver.hugl
On Sat, 21 Mar 2026 at 19:43, Mario Limonciello <superm1@kernel.org> wrote:
>
>
>
> On 3/21/26 8:52 AM, Antheas Kapenekakis wrote:
> > On Sat, 21 Mar 2026 at 14:46, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >>
> >> On Fri, 20 Mar 2026 at 21:41, Mario Limonciello (AMD) (kernel.org)
> >> <superm1@kernel.org> wrote:
> >>>
> >>>
> >>>
> >>> On 3/19/2026 7:35 AM, Antheas Kapenekakis wrote:
> >>>> On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
> >>>> <mario.limonciello@amd.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 3/17/26 07:09, Rafael J. Wysocki wrote:
> >>>>>> On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
> >>>>>> <dmitry.osipenko@collabora.com> 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 are certainly people using it, but it's more common in embedded
> >>> applications than traditional desktop distros.
> >>>
> >>> It is not a perfect match to this concept, but definitely some parallels
> >>> can be drawn.
> >>>
> >>> There are general things that might make sense if you know what the
> >>> foreground workload is or the display is off.
> >>
> >> Hm, yeah I guess so. I could see this ABI being also useful for
> >> embedded devices to control their appearance. There's precedent with
> >> e.g., charging_behaviour having dozens of device specific values,
> >> where standard and longevity are the only ones used in laptops.
> >>
> >>>>
> >>>>> 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.
> >>>
> >>> I don't know one way or the other. It would need to be prototyped to
> >>> see what it actually looked like. In the line of thinking Rafael
> >>> mentioned that platform profile was ACPI and grew to a class I would
> >>> generally just keep the design from pigeon holing too much on display
> >>> off. That's why I thought maybe foreground workload could potentially
> >>> work well.
> >>
> >> To go back to Rafael's suggestion of not using transitions for the
> >> ABI, it would be possible to push the transition logic down to the
> >> s2idle code and introduce a generic handler for it. SInce arbitrary
> >> transitions are possible under this spec, the top-level ABI
> >> implementation need not consider it.
> >>
> >> Since it is very similar to platform_profiles, it could also be
> >> potentially added there as activity_hint to the current
> >> platform_profiles implementation and mirror its conventions. This
> >> would avoid introducing new scaffolding.
> >>
> >> Then s2idle would register a platform profile handler without
> >> profiles, and instead only implement activity hint. Existing x86
> >> platform drivers could also trivially implement support for it as
> >> well. Although for WMI, the existing hooks for s2idle for Windows
> >> would handle most current drivers.
> >>
> >> An implementation for this would consist of two stages. First, the
> >> callbacks would be moved to the beginning so they can be tested
> >> independently. Then, platform_profile would be extended to support
> >> activity_hint with states {snooze, resuming, inactive, active}, and
> >> finally, s2idle would implement the handler with transition logic to
> >> make sure the callbacks get called correctly always, including when
> >> userspace ignores the file, where the full transition would occur in
> >> begin() and end().
> >>
> >> The legacy /sys/firmware/acpi/{activity_hint, activity_hint_choices}
> >> would mirror the current conventions, perhaps with a custom value as
> >> well.
> >>
> >> How does this approach sound?
> >
> > Perhaps re-using platform_profiles is not wise, after all the
> > boilerplate would be small and bolting on new hooks would be around
> > the same amount of code. New implementation would be better. How would
> > that approach sound like.
> >
> >> Antheas
> >
>
> I really don't want our top level interface for this thing to end up in
> /sys/firmware/acpi. The concept of system posture, or foreground
> workload, or whatever we call it isn't an ACPI concept. It might have
> direct implications for an ACPI implementation (IE the calling of this
> _DSM) but there is no reason we can't have a non-ACPI implementation too
> with the right knobs.
I wouldn't call platform_profile ACPI either, but it just kind of
ended up there. Where would be a better position for it?
Antheas
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-21 22:33 ` Antheas Kapenekakis
@ 2026-03-23 4:36 ` Mario Limonciello
2026-03-23 9:26 ` Antheas Kapenekakis
0 siblings, 1 reply; 41+ messages in thread
From: Mario Limonciello @ 2026-03-23 4:36 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, systemd-devel, xaver.hugl
> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
2026-03-23 4:36 ` Mario Limonciello
@ 2026-03-23 9:26 ` Antheas Kapenekakis
0 siblings, 0 replies; 41+ messages in thread
From: Antheas Kapenekakis @ 2026-03-23 9:26 UTC (permalink / raw)
To: Mario Limonciello
Cc: Rafael J. Wysocki, Dmitry Osipenko, bob.beckett, bookeldor,
hadess, jaap, kernel, lennart, linux-acpi, linux-kernel, mccann,
richard, sebastian.reichel, systemd-devel, xaver.hugl
On Mon, 23 Mar 2026 at 05:36, Mario Limonciello <superm1@kernel.org> 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
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread