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

[Zhongqiu Han]

On 8/7/2026 10:23 PM, Sibi Sankar wrote:
> On 8/6/2026 4:52 PM, Zhongqiu Han wrote:
> > Hi Sibi and Ananthu,
> >
> > On 8/6/2026 12:42 PM, Sibi Sankar wrote:
> > > From: Ananthu C V <ananthu.cv@xxxxxxxxxxxxxxxx>
> > >
> > > 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.
> > >
> > > 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 <ananthu.cv@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
> > > ---
> > >   drivers/cpufreq/freq_table.c | 7 +------
> > >   1 file changed, 1 insertion(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> > > index ea994647abc8..791118466ca4 100644
> > > --- a/drivers/cpufreq/freq_table.c
> > > +++ b/drivers/cpufreq/freq_table.c
> > > @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct 
> > > cpufreq_policy *policy)
> > >       }
> > >         policy->cpuinfo.min_freq = min_freq;
> > > -    /*
> > > -     * If the driver has set its own cpuinfo.max_freq above 
> > > max_freq, leave
> > > -     * it as is.
> > > -     */
> > > -    if (policy->cpuinfo.max_freq < max_freq)
> > > -        policy->cpuinfo.max_freq = max_freq;
> >
> > As I understand it, the guard added by commit 538b0188da46 is
> > intended for drivers (e.g. acpi-cpufreq and AMD) that may set
> > cpuinfo.max_freq above the maximum frequency in the frequency table.
> > Removing it may cause those drivers to lose their boost maximum
> > frequency.
>
> Yup, we did mention the same in the cover letter.
>
> > The regression should instead be related to commit db80ad776cd2
> > ("cpufreq: Remove driver default policy->min/max init"), which removed
> > the "policy->max = max_freq" initialization that previously allowed
> > policy->max to track the result of the boost-aware frequency scan.
> >
> > Please feel free to let me know what you think. Thanks
>
> The commit db80ad776cd2 is unrelated. The problem comes from the
> fact that policy_set_boost uses policy->cpuinfo.max_freq in it's
> freq_qos_update_request. If we modify it to use a frequency that
> adheres to the boost and per-policy boost flag instead might be
> the right thing to do here.

Hi Sibi,

Please let me know if you see any issues with the analysis below:

[Background]
Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if
max boost is known") made `cpuinfo.max_freq` hold the CPU's real
physical maximum independently of the frequency table — for drivers
whose max boost frequency is not in the table and added the
if (cpuinfo.max_freq < max_freq) guard so it can only be raised, never
lowered.


[Root cause]
Commit 6e39ba4e5a82 ("cpufreq: Add boost_freq_req QoS request") changed
the value fed to the boost QoS request from the boost-aware policy->max
computed by each driver's .set_boost() to cpuinfo.max_freq,
overloading one field with two conflicting roles: a boost ceiling that
must track boost state in both directions, and a constant physical
maximum. Only cppc_cpufreq_set_boost() and amd_pstate_cpu_boost_update()
were taught to update it in both directions; cpufreq_boost_set_sw() was
missed — it can only do so indirectly via
cpufreq_frequency_table_cpuinfo(), where the 538b0188da46 guard forbids
a decrease. So on boost-disable boost_freq_req can't be lowered and
policy->max stays pinned at the boost frequency.


[Trigger]
Before Commit db80ad776cd2 ("cpufreq: Remove driver default policy->min
max init") removed policy->max = max_freq, that write still pushed
policy->max down and masked the issue. Removing that write just made it
reproducible.


[Conclusion]
Removing the Commit 538b0188da46 guard maybe therefore not the right 
fix, the drivers that rely on it would lose their real boost maximum at 
init. The fix should belong in policy_set_boost() / 
cpufreq_boost_set_sw(): source boost_freq_req from the boost-aware table 
maximum instead of the sticky cpuinfo.max_freq. `Fixes:` should point at 
6e39ba4e5a82.


> > > +    policy->cpuinfo.max_freq = max_freq;
> > >         if (min_freq == ~0)
> > >           return -EINVAL;


--
Thx and BRs,
Zhongqiu Han