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

[Sibi Sankar <sibi.sankar@oss.qualcomm.com>]

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@oss.qualcomm.com>
>>
>> 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@oss.qualcomm.com>
>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> ---
>>   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;
>
>