kernel/git/ath/ath.git/drivers/idle, branch main

Merge tag 'x86-msr-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-15T09:38:14Z

Pull x86/msr updates from Ingo Molnar: - Large series to reorganize the rdmsr/wrmsr APIs to remove 32-bit variants and convert to 64-bit variants (Juergen Gross) - Fix W=1 warning (HyeongJun An) * tag 'x86-msr-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: x86/msr: Remove wrmsrl() x86/msr: Switch wrmsrl() users to wrmsrq() x86/msr: Remove rdmsrl() x86/msr: Switch rdmsrl() users to rdmsrq() x86/msr: Remove wrmsr_safe_on_cpu() x86/msr: Switch wrmsr_safe_on_cpu() users to wrmsrq_safe_on_cpu() x86/msr: Remove rdmsr_safe_on_cpu() x86/msr: Switch rdmsr_safe_on_cpu() users to rdmsrq_safe_on_cpu() x86/msr: Don't use rdmsr_safe_on_cpu() in rdmsrq_safe_on_cpu() x86/msr: Remove wrmsr_on_cpu() x86/msr: Switch wrmsr_on_cpu() users to wrmsrq_on_cpu() x86/msr: Remove rdmsr_on_cpu() x86/msr: Switch rdmsr_on_cpu() users to rdmsrq_on_cpu() x86/msr: Remove rdmsrl_on_cpu() x86/msr: Switch rdmsrl_on_cpu() user to rdmsrq_on_cpu() x86/process: Convert rdmsr() to rdmsrq() in arch_post_acpi_subsys_init() to address W=1 warning

x86/msr: Switch wrmsrl() users to wrmsrq()

2026-06-08T11:16:35Z

wrmsrl() is a deprecated synonym for wrmsrq(). Switch its users to wrmsrq(). Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Cc: Sean Christopherson Cc: Paolo Bonzini Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Wei Liu Cc: Dexuan Cui Cc: Long Li Cc: "Rafael J. Wysocki" Cc: Artem Bityutskiy Link: https://patch.msgid.link/20260608082809.3492719-4-jgross@suse.com

x86/msr: Switch rdmsrl() users to rdmsrq()

2026-06-08T11:16:34Z

rdmsrl() is a deprecated synonym for rdmsrq(). Switch its users to rdmsrq(). Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Wei Liu Cc: Dexuan Cui Cc: Long Li Cc: "Rafael J. Wysocki" Cc: Artem Bityutskiy Link: https://patch.msgid.link/20260608082809.3492719-2-jgross@suse.com

intel_idle: Drop C-states redundant when PC6 is disabled

2026-05-20T20:36:02Z

On modern Xeon platforms, such as Granite Rapids, Sierra Forest, and Clearwater Forest, there are two flavors of requestable C6 states: C6 and C6P. C6 allows only core C6 (CC6), while C6P allows both CC6 and package C6 (PC6). PC6 saves more power but also has a higher exit latency, so many users disable it in BIOS. When PC6 is disabled, C6P becomes identical to C6 — the CPU treats C6P requests as C6 requests. Exposing both C6 and C6P to user space in this situation is confusing: two states with the same name look different but behave the same. It also adds unnecessary overhead to the cpuidle subsystem, which is a fast path: the governor evaluates every registered state on idle entry. Drop C-states that are redundant when PC6 is disabled by marking them with CPUIDLE_FLAG_UNUSABLE, which causes cpuidle to exclude them when registering idle states. Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20260425072532.358365-5-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Introduce a helper for checking PC6

2026-05-20T20:36:02Z

Introduce the skx_is_pc6_disabled() for checking if PC6 is disabled and switch the following functions to use it: - skx_idle_state_table_update() - spr_idle_state_table_update() At the same time, clean them up improving the commentary and moving it to the function kernel-doc. Purely a clean up, no functional changes intended. Reviewed-by: Andy Shevchenko Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20260425072532.358365-4-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Add constants for MSR_PKG_CST_CONFIG_CONTROL

2026-05-20T20:36:02Z

Add two constants for the package C-state limit fields in MSR_PKG_CST_CONFIG_CONTROL. The SKX_ prefix stands for "Skylake Xeon" and makes it explicit that the mask is CPU model-specific. The same values have applied to all Xeon platforms starting from SKX. Reviewed-by: Andy Shevchenko Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20260425072532.358365-2-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Add Panther Lake C-states table

2026-03-11T11:52:00Z

Panther Lake supports the following requestable C-states: C1, C1E, C6S, C10. The parameters of these C-states should be consistent across all systems based on Panther Lake, so add a custom C-states table for it that will override C-state parameters supplied by platform firmware that may vary from one platform to another and may not represent the most optimum choice. Signed-off-by: Artem Bityutskiy [ rjw: Changelog expansion ] Link: https://patch.msgid.link/20260309083818.79588-1-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki

intel_idle: Add C-states validation

2026-01-07T20:17:43Z

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:43Z

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:42Z

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