Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled
Sibi Sankar <[email protected]> Thu, 6 Aug 2026 15:41:45 +0530
| Newsgroups | org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <[email protected]> |
On 8/6/2026 2:58 PM, Dmitry Baryshkov wrote: > On Thu, Aug 06, 2026 at 10:12:29AM +0530, Sibi Sankar wrote: >> From: Ananthu C V <[email protected]> >> >> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly >> if max boost is known") guarded cpuinfo max updates to only allow >> increases, preserving values set directly by drivers above the freq >> table maximum. This prevents cpuinfo max from decreasing on boost >> disable, leaving policy max pinned at the boost ceiling. > Why is this bad? Copy pasting logs shared from the cover letter: # cd /sys/devices/system/cpu/cpufreq/ # ls boost policy0 policy12 policy6 # cat boost 0 # cat policy6/scaling_max_freq 4454400 # echo 1 > boost # cat policy6/scaling_max_freq 4723200 # echo 0 > boost # cat policy6/scaling_max_freq 4723200 Currently disabling boost after enabling it is a NOP, scaling_max freq in this case would be pinned to turbo. It will be reachable through various govenors. Also policy specific boost flag is meaningless unless we have means to reduce the scaling_max_freq. > >> Remove the guard so cpuinfo max is always derived from the frequency >> table scan. Drivers that correctly flag boost entries are unaffected >> since the scan already excludes them when boost is off. >> >> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known") >> Signed-off-by: Ananthu C V <[email protected]> >> Signed-off-by: Sibi Sankar <[email protected]> >> --- >> drivers/cpufreq/freq_table.c | 7 +------ >> 1 file changed, 1 insertion(+), 6 deletions(-) >>