Re: [PATCH v3] cpufreq: Don't find governor for setpolicy drivers in cpufreq_init_policy()

[Yue Hu <zbestahu@gmail.com>]

On Mon, 29 Apr 2019 10:37:45 +0200
"Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:

> On Monday, April 29, 2019 9:56:40 AM CEST Yue Hu wrote:
> > On Mon, 29 Apr 2019 09:37:27 +0200
> > "Rafael J. Wysocki" <rafael@kernel.org> wrote:
> >   
> > > On Mon, Apr 29, 2019 at 9:24 AM Yue Hu <zbestahu@gmail.com> wrote:  
> > > >
> > > > From: Yue Hu <huyue2@yulong.com>
> > > >
> > > > In cpufreq_init_policy() we will check if there's last_governor for target
> > > > and setpolicy type. However last_governor is set only if has_target() is
> > > > true in cpufreq_offline(). That means find last_governor for setpolicy
> > > > type is pointless. Also new_policy.governor will not be used if ->setpolicy
> > > > callback is set in cpufreq_set_policy().
> > > >
> > > > Moreover, there's duplicate ->setpolicy check in using default policy path.
> > > > Let's add a new helper function to avoid it. Also update a little comment.
> > > >
> > > > Signed-off-by: Yue Hu <huyue2@yulong.com>    
> > > 
> > > Have you tested this with the intel_pstate driver (in the active mode)?  
> > 
> > No, just tested for ARM. It should be common logic from code perspective.  
> 
> But it is prudent to test changes on various configurations that may be affected.
> 
> Testing intel_pstate shouldn't be too difficult.
> 
> > Has any issue in this change?  
> 
> Not in principle, but I need to check the details.
> 
> In general I'm a bit hesitant to take changes that haven't been tested properly.

Ok, i will try to test it with intel_pstate driver later.

> 
> Thanks,
> Rafael
> 
> 
>