Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification

[Beata Michalska <beata.michalska@arm.com>]

On Mon, Aug 25, 2025 at 10:26:41AM +0530, Viresh Kumar wrote:
> On 23-08-25, 00:17, Prashant Malani wrote:
> > Some cpufreq drivers have a get() function which can return an unreliable
> > frequency. This can cause issues when switching governors. For instance,
> > a CPU would be on performance governor and have it's frequency (and
> > policy->cur) set to max. When the governor is switched to userspace, the
> > policy->cur is re-used, but it is checked against the frequency returned
> > by the driver's get() function. If it's different, the frequency will
> > get set to the new (incorrect) value.
> > 
> > To avoid this, add a flag that avoids this verify step on governor start
> > if the cpufreq driver opts in to it.
> > 
> > Since there are no users of this flag, no functional changes are
> > introduced here.
> > 
> > Cc: Beata Michalska <beata.michalska@arm.com>
> > Signed-off-by: Prashant Malani <pmalani@google.com>
> > ---
> >  drivers/cpufreq/cpufreq.c |  3 ++-
> >  include/linux/cpufreq.h   | 10 ++++++++++
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index b8937737d096..72e6552a40ea 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy)
> >  
> >  	pr_debug("%s: for CPU %u\n", __func__, policy->cpu);
> >  
> > -	cpufreq_verify_current_freq(policy, false);
> > +	if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START))
> > +		cpufreq_verify_current_freq(policy, false);
> 
> I don't think it is okay to do this to hide a driver's failure to
> return the right frequency. What about all the other places where
> get() is still used ? Won't that cause similar issues elsewhere ?
> 
> The driver must be fixed for this, not the core. The core is doing the
Agreed.

---
BR
Beata
> right thing here, asking the driver to return the current frequency.
> If the driver is unsure, it can just return the current frequency from
> policy->cur instead.
> 
> -- 
> viresh