Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

On Thu, Aug 06, 2026 at 03:41:45PM +0530, Sibi Sankar wrote:
> 
> 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

How is this different from the maximum frequency being unavailable, for
example, because of the thermal pressure?

> 
> 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(-)
> > > 

-- 
With best wishes
Dmitry