linux.git/drivers/cpufreq, branch v6.17.12

cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writes

2025-11-24T09:37:33+00:00

[ Upstream commit 4b747cc628d8f500d56cf1338280eacc66362ff3 ]

Commit ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in
legacy mode") introduced a check for feature X86_FEATURE_IDA to verify
turbo mode support. Although this is the correct way to check for turbo
mode support, it causes issues on some platforms that disable turbo
during OS boot, but enable it later [1]. Before adding this feature
check, users were able to get turbo mode frequencies by writing 0 to
/sys/devices/system/cpu/intel_pstate/no_turbo post-boot.

To restore the old behavior on the affected systems while still
addressing the unchecked MSR issue on some Skylake-X systems, check
X86_FEATURE_IDA only immediately before updates of MSR_IA32_PERF_CTL
that may involve setting the Turbo Engage Bit (bit 32).

Fixes: ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode")
Reported-by: Aaron Rainbolt 
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122531 [1]
Tested-by: Aaron Rainbolt 
Signed-off-by: Srinivas Pandruvada 
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20251111010840.141490-1-srinivas.pandruvada@linux.intel.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq: tegra186: Initialize all cores to max frequencies

2025-11-13T20:37:37+00:00

[ Upstream commit ba6018929165fc914c665f071f8e8cdbac844a49 ]

During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
are still at reset values and not reflecting the actual frequency. This
causes get calls to fail. Set all cores to their respective max
frequency during probe to initialize the registers to working values.

Suggested-by: Mikko Perttunen 
Signed-off-by: Aaron Kling 
Reviewed-by: Mikko Perttunen 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: ondemand: Update the efficient idle check for Intel extended Families

2025-11-13T20:36:49+00:00

[ Upstream commit 7f3cfb7943d27a7b61bdac8db739cf0bdc28e87d ]

IO time is considered busy by default for modern Intel processors. The
current check covers recent Family 6 models but excludes the brand new
Families 18 and 19.

According to Arjan van de Ven, the model check was mainly due to a lack
of testing on systems before INTEL_CORE2_MEROM. He suggests considering
all Intel processors as having an efficient idle.

Extend the IO busy classification to all Intel processors starting with
Family 6, including Family 15 (Pentium 4s) and upcoming Families 18/19.

Use an x86 VFM check and move the function to the header file to avoid
using arch-specific #ifdefs in the C file.

Signed-off-by: Sohil Mehta 
Link: https://patch.msgid.link/20250908230655.2562440-1-sohil.mehta@intel.com
[ rjw: Added empty line after #include ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq/longhaul: handle NULL policy in longhaul_exit

2025-11-13T20:36:47+00:00

[ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ]

longhaul_exit() was calling cpufreq_cpu_get(0) without checking
for a NULL policy pointer. On some systems, this could lead to a
NULL dereference and a kernel warning or panic.

This patch adds a check using unlikely() and returns early if the
policy is NULL.

Bugzilla: #219962

Signed-off-by: Dennis Beier 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: ti: Add support for AM62D2

2025-11-13T20:36:46+00:00

[ Upstream commit b5af45302ebc141662b2b60c713c9202e88c943c ]

Add support for TI K3 AM62D2 SoC to read speed and revision values
from hardware and pass to OPP layer. AM62D shares the same configuations
as AM62A so use existing am62a7_soc_data.

Signed-off-by: Paresh Bhagat 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq/amd-pstate: Fix a regression leading to EPP 0 after hibernate

2025-10-29T13:10:18+00:00

[ Upstream commit 85d7dda5a9f665ea579741ec873a8841f37e8943 ]

After resuming from S4, all CPUs except the boot CPU have the wrong EPP
hint programmed.  This is because when the CPUs were offlined the EPP value
was reset to 0.

This is a similar problem as fixed by
commit ba3319e590571 ("cpufreq/amd-pstate: Fix a regression leading to EPP
0 after resume") and the solution is also similar.  When offlining rather
than reset the values to zero, reset them to match those chosen by the
policy. When the CPUs are onlined again these values will be restored.

Closes: https://community.frame.work/t/increased-power-usage-after-resuming-from-suspend-on-ryzen-7040-kernel-6-15-regression/74531/20?u=mario_limonciello
Fixes: 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Mario Limonciello (AMD) 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()

2025-10-19T14:37:24+00:00

commit 69e5d50fcf4093fb3f9f41c4f931f12c2ca8c467 upstream.

The cpufreq_cpu_put() call in update_qos_request() takes place too early
because the latter subsequently calls freq_qos_update_request() that
indirectly accesses the policy object in question through the QoS request
object passed to it.

Fortunately, update_qos_request() is called under intel_pstate_driver_lock,
so this issue does not matter for changing the intel_pstate operation
mode, but it theoretically can cause a crash to occur on CPU device hot
removal (which currently can only happen in virt, but it is formally
supported nevertheless).

Address this issue by modifying update_qos_request() to drop the
reference to the policy later.

Fixes: da5c504c7aae ("cpufreq: intel_pstate: Implement QoS supported freq constraints")
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Zihuan Zhang 
Link: https://patch.msgid.link/2255671.irdbgypaU6@rafael.j.wysocki
Signed-off-by: Greg Kroah-Hartman

cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay

2025-10-19T14:37:24+00:00

commit f965d111e68f4a993cc44d487d416e3d954eea11 upstream.

If cppc_get_transition_latency() returns CPUFREQ_ETERNAL to indicate a
failure to retrieve the transition latency value from the platform
firmware, the CPPC cpufreq driver will use that value (converted to
microseconds) as the policy transition delay, but it is way too large
for any practical use.

Address this by making the driver use the cpufreq's default
transition latency value (in microseconds) as the transition delay
if CPUFREQ_ETERNAL is returned by cppc_get_transition_latency().

Fixes: d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us")
Cc: 5.19+  # 5.19
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mario Limonciello (AMD) 
Reviewed-by: Jie Zhan 
Acked-by: Viresh Kumar 
Reviewed-by: Qais Yousef 
Signed-off-by: Greg Kroah-Hartman

cpufreq: tegra186: Set target frequency for all cpus in policy

2025-10-19T14:37:07+00:00

[ Upstream commit 0b1bb980fd7cae126ee3d59f817068a13e321b07 ]

The original commit set all cores in a cluster to a shared policy, but
did not update set_target to apply a frequency change to all cores for
the policy. This caused most cores to remain stuck at their boot
frequency.

Fixes: be4ae8c19492 ("cpufreq: tegra186: Share policy per cluster")
Signed-off-by: Aaron Kling 
Reviewed-by: Mikko Perttunen 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency

2025-10-19T14:37:00+00:00

commit f97aef092e199c10a3da96ae79b571edd5362faa upstream.

Commit a755d0e2d41b ("cpufreq: Honour transition_latency over
transition_delay_us") caused platforms where cpuinfo.transition_latency
is CPUFREQ_ETERNAL to get a very large transition latency whereas
previously it had been capped at 10 ms (and later at 2 ms).

This led to a user-observable regression between 6.6 and 6.12 as
described by Shawn:

"The dbs sampling_rate was 10000 us on 6.6 and suddently becomes
 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these platforms
 because the default transition delay was dropped [...].

 It slows down dbs governor's reacting to CPU loading change
 dramatically.  Also, as transition_delay_us is used by schedutil
 governor as rate_limit_us, it shows a negative impact on device
 idle power consumption, because the device gets slightly less time
 in the lowest OPP."

Evidently, the expectation of the drivers using CPUFREQ_ETERNAL as
cpuinfo.transition_latency was that it would be capped by the core,
but they may as well return a default transition latency value instead
of CPUFREQ_ETERNAL and the core need not do anything with it.

Accordingly, introduce CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS and make
all of the drivers in question use it instead of CPUFREQ_ETERNAL.  Also
update the related Rust binding.

Fixes: a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us")
Closes: https://lore.kernel.org/linux-pm/20250922125929.453444-1-shawnguo2@yeah.net/
Reported-by: Shawn Guo 
Reviewed-by: Mario Limonciello (AMD) 
Reviewed-by: Jie Zhan 
Acked-by: Viresh Kumar 
Cc: 6.6+  # 6.6+
Signed-off-by: Rafael J. Wysocki 
Link: https://patch.msgid.link/2264949.irdbgypaU6@rafael.j.wysocki
[ rjw: Fix typo in new symbol name, drop redundant type cast from Rust binding ]
Tested-by: Shawn Guo  # with cpufreq-dt driver
Reviewed-by: Qais Yousef 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman