[PATCH v2 0/1] cpuidle: sysfs: Display idle state enter function name

[PATCH v2 0/1] cpuidle: sysfs: Display idle state enter function name

[Aaron Tomlin]

Changes since v1 [1]:

 - Correct commit message

[1]: https://lore.kernel.org/lkml/20251118232208.660255-1-atomlin@atomlin.com/

Aaron Tomlin (1):
  cpuidle: sysfs: Display idle state enter function name

 Documentation/ABI/testing/sysfs-devices-system-cpu | 7 +++++++
 drivers/cpuidle/sysfs.c                            | 9 +++++++++
 2 files changed, 16 insertions(+)

-- 
2.51.0

[PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

[Aaron Tomlin]

This patch introduces a read-only "enter_function" attribute to the
cpuidle sysfs interface. It exports the kernel symbolic name of the
enter callback responsible for executing the CPU idle state entry
state->enter(). It allows users to reliably map an abstract C-state
e.g., "C0", to its concrete kernel implementation (e.g., poll_idle).

Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 7 +++++++
 drivers/cpuidle/sysfs.c                            | 9 +++++++++
 2 files changed, 16 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 8aed6d94c4cd..7be4555d502a 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -217,6 +217,13 @@ Description:
 		time (in microseconds) this cpu should spend in this idle state
 		to make the transition worth the effort.
 
+What:		/sys/devices/system/cpu/cpuX/cpuidle/state<N>/enter_function
+Date:		November 2025
+KernelVersion:	v6.18
+Contact:	Linux power management list <linux-pm@vger.kernel.org>
+Description:
+		(RO) Display the symbolic name of the idle state's enter callback.
+
 What:		/sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/
 Date:		March 2018
 KernelVersion:	v4.17
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 61de64817604..dbd8d796ad29 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -314,6 +314,13 @@ static ssize_t show_state_default_status(struct cpuidle_state *state,
 		       state->flags & CPUIDLE_FLAG_OFF ? "disabled" : "enabled");
 }
 
+static ssize_t show_state_enter_function(struct cpuidle_state *state,
+					 struct cpuidle_state_usage *state_usage,
+					 char *buf)
+{
+	return sysfs_emit(buf, "%ps\n", state->enter);
+}
+
 define_one_state_ro(name, show_state_name);
 define_one_state_ro(desc, show_state_desc);
 define_one_state_ro(latency, show_state_exit_latency);
@@ -326,6 +333,7 @@ define_one_state_rw(disable, show_state_disable, store_state_disable);
 define_one_state_ro(above, show_state_above);
 define_one_state_ro(below, show_state_below);
 define_one_state_ro(default_status, show_state_default_status);
+define_one_state_ro(enter_function, show_state_enter_function);
 
 static struct attribute *cpuidle_state_default_attrs[] = {
 	&attr_name.attr,
@@ -340,6 +348,7 @@ static struct attribute *cpuidle_state_default_attrs[] = {
 	&attr_above.attr,
 	&attr_below.attr,
 	&attr_default_status.attr,
+	&attr_enter_function.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(cpuidle_state_default);
-- 
2.51.0

Re: [PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

[Rafael J. Wysocki]

On Wed, Nov 19, 2025 at 1:26 AM Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> This patch introduces a read-only "enter_function" attribute to the
> cpuidle sysfs interface. It exports the kernel symbolic name of the
> enter callback responsible for executing the CPU idle state entry
> state->enter(). It allows users to reliably map an abstract C-state
> e.g., "C0", to its concrete kernel implementation (e.g., poll_idle).
>
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>

I'm not really sure how this helps.

For example, the intel_idle driver uses the same function for all idle
states except for the polling one, which is already advertised as
polling.

Besides, why do you want users to look into the kernel source code to
figure things out?

> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 7 +++++++
>  drivers/cpuidle/sysfs.c                            | 9 +++++++++
>  2 files changed, 16 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index 8aed6d94c4cd..7be4555d502a 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -217,6 +217,13 @@ Description:
>                 time (in microseconds) this cpu should spend in this idle state
>                 to make the transition worth the effort.
>
> +What:          /sys/devices/system/cpu/cpuX/cpuidle/state<N>/enter_function
> +Date:          November 2025
> +KernelVersion: v6.18
> +Contact:       Linux power management list <linux-pm@vger.kernel.org>
> +Description:
> +               (RO) Display the symbolic name of the idle state's enter callback.
> +
>  What:          /sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/
>  Date:          March 2018
>  KernelVersion: v4.17
> diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> index 61de64817604..dbd8d796ad29 100644
> --- a/drivers/cpuidle/sysfs.c
> +++ b/drivers/cpuidle/sysfs.c
> @@ -314,6 +314,13 @@ static ssize_t show_state_default_status(struct cpuidle_state *state,
>                        state->flags & CPUIDLE_FLAG_OFF ? "disabled" : "enabled");
>  }
>
> +static ssize_t show_state_enter_function(struct cpuidle_state *state,
> +                                        struct cpuidle_state_usage *state_usage,
> +                                        char *buf)
> +{
> +       return sysfs_emit(buf, "%ps\n", state->enter);
> +}
> +
>  define_one_state_ro(name, show_state_name);
>  define_one_state_ro(desc, show_state_desc);
>  define_one_state_ro(latency, show_state_exit_latency);
> @@ -326,6 +333,7 @@ define_one_state_rw(disable, show_state_disable, store_state_disable);
>  define_one_state_ro(above, show_state_above);
>  define_one_state_ro(below, show_state_below);
>  define_one_state_ro(default_status, show_state_default_status);
> +define_one_state_ro(enter_function, show_state_enter_function);
>
>  static struct attribute *cpuidle_state_default_attrs[] = {
>         &attr_name.attr,
> @@ -340,6 +348,7 @@ static struct attribute *cpuidle_state_default_attrs[] = {
>         &attr_above.attr,
>         &attr_below.attr,
>         &attr_default_status.attr,
> +       &attr_enter_function.attr,
>         NULL
>  };
>  ATTRIBUTE_GROUPS(cpuidle_state_default);
> --
> 2.51.0
>
>

Re: [PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

[Aaron Tomlin]

On Thu, Nov 20, 2025 at 04:36:21PM +0100, Rafael J. Wysocki wrote:
> I'm not really sure how this helps.
> 
> For example, the intel_idle driver uses the same function for all idle
> states except for the polling one, which is already advertised as
> polling.
> 
> Besides, why do you want users to look into the kernel source code to
> figure things out?

Hi Rafael,

While intel_idle uses a single function for most states today, other
cpuidle drivers, different architectures, or future changes might implement
per-state variations.

The mapping from abstract C-state names and descriptions (e.g., "C1", "C3")
to the actual kernel implementation might not always be clear. Exposing the
enter function offers a direct, cheap and reliable way to easily identify
what is being executed for each state without using a kernel debugger
(e.g., crash(8). Finally user-space tools might benefit from introspecting
implementation details at runtime to validate configuration. This is
primarily for the advanced user.

Please let me know if this clarifies the motivation. 


Kind regards,
-- 
Aaron Tomlin

Re: [PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

[Rafael J. Wysocki]

On Fri, Nov 21, 2025 at 4:16 AM Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> On Thu, Nov 20, 2025 at 04:36:21PM +0100, Rafael J. Wysocki wrote:
> > I'm not really sure how this helps.
> >
> > For example, the intel_idle driver uses the same function for all idle
> > states except for the polling one, which is already advertised as
> > polling.
> >
> > Besides, why do you want users to look into the kernel source code to
> > figure things out?
>
> Hi Rafael,
>
> While intel_idle uses a single function for most states today, other
> cpuidle drivers, different architectures, or future changes might implement
> per-state variations.
>
> The mapping from abstract C-state names and descriptions (e.g., "C1", "C3")
> to the actual kernel implementation might not always be clear. Exposing the
> enter function offers a direct, cheap and reliable way to easily identify
> what is being executed for each state without using a kernel debugger
> (e.g., crash(8). Finally user-space tools might benefit from introspecting
> implementation details at runtime to validate configuration. This is
> primarily for the advanced user.
>
> Please let me know if this clarifies the motivation.

No, it doesn't.  You'd need to tell me specifically what use case is
going to be addressed by this change.

Though this is not going to fly regardless because exposing kernel
internals via sysfs turns them into ABI which may hinder future
improvements.

So let's first talk about what problem there is that needs addressing.

Re: [PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

[Aaron Tomlin]

On Fri, Nov 21, 2025 at 02:31:44PM +0100, Rafael J. Wysocki wrote:
> No, it doesn't.  You'd need to tell me specifically what use case is
> going to be addressed by this change.
> 
> Though this is not going to fly regardless because exposing kernel
> internals via sysfs turns them into ABI which may hinder future
> improvements.
> 
> So let's first talk about what problem there is that needs addressing.

Hi Rafeal,

Apologies for the delay. I understand that turning internal details into an
ABI can severely hinder future improvements, and I acknowledge that this is
a critical barrier for the current approach. I do not currently have a more
specific or compelling use case beyond this initial need.

Please ignore this patch.


Kind regards,
-- 
Aaron Tomlin