Re: [PATCH v1 2/6] cpufreq: intel_pstate: Do not update global.turbo_disabled after initialization

[srinivas pandruvada]

On Fri, 2024-06-07 at 17:04 +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 5, 2024 at 2:05 PM srinivas pandruvada
> <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote:
> > 
> > On Wed, 2024-06-05 at 13:21 +0800, Xi Ruoyao wrote:
> > > On Tue, 2024-06-04 at 09:56 -0700, srinivas pandruvada wrote:
> > > > > > With such a delay, I am not sure how this even worked
> > > > > > before.
> > > 
> > > It didn't work out of box but it worked after manually writing 0
> > > to
> > > no_turbo after 20 seconds, see
> > > https://bugzilla.kernel.org/show_bug.cgi?id=218702.
> > 
> > That make sense. So it never worked out of box. The
> > store_no_turbo()
> > has additional read for turbo flag before, which is removed now. I
> > think adding that back will will restore old behavior.
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 4b986c044741..0d5330e5b96b 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -1301,6 +1301,8 @@ static ssize_t store_no_turbo(struct kobject
> > *a,
> > struct kobj_attribute *b,
> > 
> >         no_turbo = !!clamp_t(int, input, 0, 1);
> > 
> > +       global.turbo_disabled = turbo_is_disabled();
> > +
> >         if (no_turbo == global.no_turbo)
> >                 goto unlock_driver;
> > 
> > 
> > Need to adjust the mutex around it also.
> 
> Anyhow, it can be made work.
> 
> global.turbo_disabled can be updated right before it is checked in
> store_no_turbo(), so if 0 is written to no_turbo (and global.no_turbo
> is 1), it will succeed if global.turbo_disabled changes from 1 to 0.
> 
> Something like the attached (untested) patch.

Should work.

Xi,
Please test so that we can close this issue.

Thanks,
Srinivas