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

[Sibi Sankar]

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.

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