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 Dietmar,

On Mon, Oct 12, 2026 at 01:42:39AM +0200, Dietmar Eggemann wrote:
> On 29.09.26 13:38, 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.
> > 
> > Fixes: db80ad776cd2 ("cpufreq: Remove driver default policy->min/max init")
> > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > ---
> >  drivers/cpufreq/cpufreq.c    | 16 +++++++++++++++-
> >  drivers/cpufreq/freq_table.c |  9 ++++++++-
> >  include/linux/cpufreq.h      |  3 +++
> >  3 files changed, 26 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 96515880b4ac..5e6afb6f8826 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -574,6 +574,8 @@ static ssize_t show_local_boost(struct cpufreq_policy *policy, char *buf)
> >  
> >  static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
> >  {
> > +	unsigned int max_freq;
> > +	unsigned int max_table_freq;
> >  	int ret;
> >  
> >  	if (policy->boost_enabled == enable)
> > @@ -587,7 +589,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
> >  		return ret;
> >  	}
> >  
> > -	ret = freq_qos_update_request(&policy->boost_freq_req, policy->cpuinfo.max_freq);
> > +	max_table_freq = cpufreq_frequency_table_max(policy);
> > +
> > +	if (policy_has_boost_freq(policy)) {
> > +		max_freq = enable ? max_table_freq : policy->cpuinfo.max_base_freq;
> > +
> > +		if (!max_freq)
> > +			/* when the freq table contains only boost frequencies */
> > +			max_freq = max_table_freq;
> > +	} else {
> > +		max_freq = policy->cpuinfo.max_freq;
> > +	}
> > +
> > +	ret = freq_qos_update_request(&policy->boost_freq_req, max_freq);
> 
> This looks pretty convoluted. You have to find the correct freq argument
> for freq_qos_update_request() for freq_table drivers but work around
> this for e.g. the CPPC driver.

We do need quite a bit of wrangling to account for every case, which is why I
didn't like the idea of having to deal with all of this in core to begin with.
My initial idea (revision 1) was to simply drop the one way guard from core
and have the drivers deal with it in some way, but we wanted to keep it,
I suppose. I am open for suggestions, but my guess is that if we have to keep
implementing these fixes in core itself, it will be convoluted in one way or
other.

Best,
Ananthu