Re: [PATCH v3 2/2] cpufreq: fix policy max not returning to non-boost freq on boost disable

[Ananthu C V <ananthu.cv@oss.qualcomm.com>]

Hi Viresh,

On Mon, Nov 02, 2026 at 02:08:39PM +0530, Viresh Kumar wrote:
> Hi,
> 
> On 29-09-26, 17:08, Ananthu C V wrote:
> > Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if
> > max boost is known") introduced a guard for cpuinfo max updates to only
> > increase, to preserve driver-set values above the freq table maximum.
> > Later commit db80ad776cd2 ("cpufreq: Remove driver default policy->min/max
> > init") dropped the 'policy->max = max_freq' assignment from
> > cpufreq_frequency_table_cpuinfo, leaving that one-way-guard to be the only
> > path for cpuinfo max and consequently policy max to be updated, causing
> > both values to be stuck at boost frequency even when boost is disabled.
> > 
> > Unconditionally track the highest non-boost frequency (max_base_freq)
> > in the freq table. If boost frequencies are available, use the highest
> > frequency from the table/max_base_freq instead of cpuinfo->max_freq to
> > control boost values, so the value can decrease again when boost is
> > disabled.
> 
> If this is a fix, it should be submitted separately so we can get this merged
> independently.

After thinking more about this, this should be the way to go about it. This
issue is currently harmless because boost values cannot be actually utilized
and hence the value getting stuck in boost is a no-op. But once the fix to
the initial problem is applied, this will become an actual problem that causes
the active frequency to be stuck at boost. So I guess this will need an
independent fix that comes first in the series.

> > Fixes: db80ad776cd2 ("cpufreq: Remove driver default policy->min/max init")
> 
> I am not able to understand the current problem though. I see from the sequence
> of events mentioned in your cover-letter that scaling_max_freq doesn't return
> back, but why ?

cpuinfo.max_freq value is currently updated with a conditional guard, which is:

if (policy->cpuinfo.max_freq < max_freq)

This means the value only goes up, and never comes down.

> And does a simple revert of the above commit (just freq_table.c) fixes it ?

I gave this a try, and the simple answer is yes. The diff would be:

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index ea994647abc8..5b364d8da4f9 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -49,15 +49,16 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
                        max_freq = freq;
        }

-       policy->cpuinfo.min_freq = min_freq;
+       policy->min = policy->cpuinfo.min_freq = min_freq;
+       policy->max = max_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;
+               policy->max = policy->cpuinfo.max_freq = max_freq;

-       if (min_freq == ~0)
+       if (policy->min == ~0)
                return -EINVAL;
        else
                return 0;

I am pretty sure we can maintain the policy->min status quo and only touch the
policy->max updation; which from a passing glance simply seems inconsequential.
Potential side effects, if any, aside, this would at least fix the issue at
hand, which is the frequency getting stuck on a higher value without being able
to come down. What do you think about this?

Best,
Ananthu