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

Sibi Sankar <[email protected]>
Newsgroups org.kernel.vger.linux-pm,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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 <[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.
>>
>> 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(-)
>>
>> 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;
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.