kernel/linux.git/drivers/idle, branch v7.0-rc7

intel_idle: Add C-states validation

2026-01-07T20:17:43+00:00

Add validation for C-states specified via the "table=" module parameter. Treat this module parameter as untrusted input and validate it thoroughly. Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20251216080402.156988-4-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Add cmdline option to adjust C-states table

2026-01-07T20:17:43+00:00

Add a new module parameter that allows adjusting the C-states table used by the driver. Currently, the C-states table is hardcoded in the driver based on the CPU model. The goal is to have good enough defaults for most users. However, C-state characteristics, such as exit latency and residency, can vary between different variants of the same CPU model and BIOS settings. Moreover, different platform usage models and user preferences may benefit from different C-state target_residency values. Provide a way for users to adjust the C-states table via a module parameter "table". The general format is: "state1:latency1:target_residency1,state2:latency2:target_residency2,..." In other words, represent each C-state by its name, exit latency (in microseconds), and target residency (in microseconds), separated by colons. Separate multiple C-states by commas. For example, suppose a CPU has 3 C-states with the following characteristics: C1: exit_latency=1, target_residency=2 C1E: exit_latency=10, target_residency=10 C6: exit_latency=100, target_residency=500 Users can specify a custom C-states table as follows: 1. intel_idle.table="C1:2:2,C1E:5:20,C6:150:600" Result: C1: exit_latency=2, target_residency=2 C1E: exit_latency=5, target_residency=20 C6: exit_latency=150, target_residency=600 2. intel_idle.table="C6::400" Result: C1: exit_latency=1, target_residency=2 (unchanged) C1E: exit_latency=10, target_residency=10 (unchanged) C6: exit_latency=100, target_residency=400 (only target_residency changed) Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20251216080402.156988-3-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Initialize sysfs after cpuidle driver initialization

2026-01-07T20:17:42+00:00

Reorder initialization calls to initialize the internal driver data before sysfs: Was: intel_idle_sysfs_init(); intel_idle_cpuidle_driver_init(); Now: intel_idle_cpuidle_driver_init(); intel_idle_sysfs_init(); Follow the general principle that drivers should initialize internal state before registering external interfaces like sysfs, avoiding potential usage before full initialization. Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20251216080402.156988-2-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Remove the 'preferred_cstates' parameter

2026-01-07T20:13:09+00:00

Remove the 'preferred_cstates' module parameter as it is not really useful. The parameter currently only affects Alder Lake, where it controls C1/C1E preference, with C1E being the default. The parameter does not support any other platform. For example, Meteor Lake has a similar C1/C1E limitation, but the parameter does not support Meteor Lake. This indicates that the parameter is not very useful. Generally, independent C1 and C1E are important for server platforms where low latency is key. However, they are not as important for client platforms, like Alder Lake, where C1E providing better energy savings is generally preferred. The parameter was originally introduced for Sapphire Rapids Xeon: da0e58c038e6 intel_idle: add 'preferred_cstates' module argument Later it was added to Alder Lake: d1cf8bbfed1ed ("intel_idle: Add AlderLake support") But it was removed from Sapphire Rapids when firmware fixed the C1/C1E limitation: 1548fac47a114 ("intel_idle: make SPR C1 and C1E be independent") So Alder Lake is the only platform left where this parameter has any effect. Remove this parameter to simplify the driver and reduce maintenance burden. Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20251215111300.132803-1-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Remove unused driver version constant

2026-01-07T20:11:42+00:00

The INTEL_IDLE_VERSION constant has not been updated since 2020 and serves no useful purpose. The driver version is implicitly defined by the kernel version, making this constant redundant. Remove the constant to eliminate potential confusion about version tracking. Signed-off-by: Artem Bityutskiy Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20251215111229.132705-1-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Remove unnecessary address-of operators

2025-09-01T15:32:25+00:00

Remove redundant address-of operators (&) when assigning the intel_idle() function pointer to the .enter field in cpuidle_state structures.in C, the & is not needed for function names. This change improves code consistency and readability by using the more conventional form without the & operator. No functional change intended. Signed-off-by: Kaushlendra Kumar Reviewed-by: Artem Bityutskiy Link: https://patch.msgid.link/20250818085124.3897921-1-kaushlendra.kumar@intel.com Signed-off-by: Rafael J. Wysocki

intel_idle: Allow loading ACPI tables for any family

2025-08-11T19:43:26+00:00

There is no reason to limit intel_idle's loading of ACPI tables to family 6. Upcoming Intel processors are not in family 6. Below "Fixes" really means "applies cleanly until". That syntax commit didn't change the previous logic, but shows this patch applies back 5-years. Fixes: 4a9f45a0533f ("intel_idle: Convert to new X86 CPU match macros") Signed-off-by: Len Brown Link: https://patch.msgid.link/06101aa4fe784e5b0be1cb2c0bdd9afcf16bd9d4.1754681697.git.len.brown@intel.com Signed-off-by: Rafael J. Wysocki

intel_idle: Update arguments of mwait_idle_with_hints()

2025-06-10T19:09:28+00:00

Commit a17b37a3f416 ("x86/idle: Change arguments of mwait_idle_with_hints() to u32") changed the type of arguments of mwait_idle_with_hints() from unsigned long to u32. Change the type of variables in the call to mwait_idle_with_hints() to unsigned int to follow the change. Signed-off-by: Uros Bizjak Reviewed-by: Artem Bityutskiy Link: https://patch.msgid.link/20250609063528.48715-1-ubizjak@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Rescan "dead" SMT siblings during initialization

2025-06-07T12:23:22+00:00

Make intel_idle_init() call arch_cpu_rescan_dead_smt_siblings() after successfully registering intel_idle as the cpuidle driver so as to allow the "dead" SMT siblings (if any) to go into deep idle states. This is necessary for the processor to be able to reach deep package C-states (like PC10) going forward which is requisite for reducing power sufficiently in suspend-to-idle, among other things. Signed-off-by: Rafael J. Wysocki Tested-by: Artem Bityutskiy Link: https://patch.msgid.link/10669885.nUPlyArG6x@rjwysocki.net

intel_idle: Use subsys_initcall_sync() for initialization

2025-06-06T15:49:39+00:00

It is not necessary to wait until the device_initcall() stage with intel_idle initialization. All of its dependencies are met after all subsys_initcall()s have run, so subsys_initcall_sync() can be used for initializing it. It is also better to ensure that intel_idle will always initialize before the ACPI processor driver that uses module_init() for its initialization. Signed-off-by: Rafael J. Wysocki Tested-by: Artem Bityutskiy Link: https://patch.msgid.link/2994397.e9J7NaK4W3@rjwysocki.net