[PATCH] ACPI: processor: thermal: Do not leave a stale limit when not throttling

[Ashton A. via B4 Relay]

From: "Ashton A." <me@xxxxxxxxxxxxxxxx>

cpufreq_update_thermal_limit() sets thermal_req to cpuinfo.max_freq
scaled by the reduction step, also at step 0, when no throttling is
requested. cpuinfo.max_freq drops to the nominal frequency while boost
is disabled (amd-pstate, and intel_pstate with no_turbo), so a cooling
state update in that window leaves thermal_req at the nominal frequency
after boost is enabled again. The CPU then stays at its base clock
until the next cooling state change.

On systems with an ACPI thermal zone that has a passive trip (_PSV)
with the processors in its _PSL, such an update happens on every
resume, when the zone is re-initialized and step_wise re-applies the
cooling state. Suspending with boost disabled, e.g. in
power-profiles-daemon's "power-saver" profile, and switching back to
"performance" after resume is enough to hit this.

Before commit d15ce412737a ("ACPI: cpufreq: Switch to QoS requests
instead of cpufreq notifier"), the limit was recomputed on every policy
update and could not go stale.

Use FREQ_QOS_MAX_DEFAULT_VALUE at step 0, the value the request is
created with. ->verify() already clamps policy limits to
cpuinfo.max_freq, so this only drops the stale limit.

Reproducer on v7.3, ASUS ROG Flow Z13 (Ryzen AI MAX+ 395, amd-pstate
active), with N being any "Processor" cooling device:

  echo 0 > /sys/devices/system/cpu/cpufreq/boost
  cat /sys/class/thermal/cooling_deviceN/cur_state \
    > /sys/class/thermal/cooling_deviceN/cur_state
  echo 1 > /sys/devices/system/cpu/cpufreq/boost
  cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq

This prints 3000000 instead of 5187500. With this patch it prints
5187500, also after the power-profiles-daemon suspend and resume
sequence above.

Bug 221795 reports the same symptom on another ASUS laptop with the
same kind of ACPI thermal zone.

The issue was diagnosed and this patch drafted with an AI coding
assistant (Claude Code, Claude Opus 5.5). I have reviewed the cause
and fix, and I take full responsibility for this commit and the fix
included.

Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221795
Signed-off-by: Ashton A. <me@xxxxxxxxxxxxxxxx>
---
 drivers/acpi/processor_thermal.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/processor_thermal.c b/drivers/acpi/processor_thermal.c
index 11036f0d2b9..3663a54c043 100644
--- a/drivers/acpi/processor_thermal.c
+++ b/drivers/acpi/processor_thermal.c
@@ -97,8 +97,15 @@ static bool cpufreq_update_thermal_limit(unsigned int cpu, struct acpi_processor
 	if (!policy)
 		return false;
 
-	max_freq = (policy->cpuinfo.max_freq *
-		(100 - reduction_step(cpu) * cpufreq_thermal_reduction_pctg)) / 100;
+	/*
+	 * cpuinfo.max_freq changes when boost is toggled, so storing it when
+	 * no reduction is requested would leave a stale limit behind.
+	 */
+	if (!reduction_step(cpu))
+		max_freq = FREQ_QOS_MAX_DEFAULT_VALUE;
+	else
+		max_freq = (policy->cpuinfo.max_freq *
+			(100 - reduction_step(cpu) * cpufreq_thermal_reduction_pctg)) / 100;
 
 	ret = freq_qos_update_request(&pr->thermal_req, max_freq);
 	if (ret < 0) {

---
base-commit: 65ba8f34ec886ec72b2c07ddc8cf3d815c32869d
change-id: 20261028-acpi-thermal-stale-limit-7a1b102a1bdb

Best regards,
--  
Ashton A. <me@xxxxxxxxxxxxxxxx>