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 5:42 PM, Dmitry Baryshkov wrote:
> 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 <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.
>>> 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?

It's certainly different because the maximum frequency is available in this
case. Consider the following scenario where we use the performance
governor with boost disabled -> enabled -> disabled. The governor would
be voting for the max possible frequency, which is the boost frequency even
when boost is explicitly disabled.

# cat boost
0

# cat policy6/scaling_max_freq
4454400

# echo performance > policy6/scaling_governor
# cat policy6/stats/time_in_state
...
4454400 377
4588800 0
4723200 0

# cat policy6/stats/time_in_state
...
4454400 480
4588800 0
4723200 0

# echo 1 > boost
#
#
# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 200

# echo 0 > boost

# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 1048

# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 1115

Shouldn't this behavior be fixed? The boost flag and per-policy boost flag
have no meaning otherwise.

-Sibi

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