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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Monday, May 13, 2019 4:11:40 AM CEST Yue Hu wrote:
> 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.
> 
> Hi Rafael,
> 
> Sorry for late test since i take time to emulate/find the board with Sandy brigdge
> processor.
> 
> I'm sure intel_pstate setpolicy driver is working fine by tests containing policy init,
> hotplug and changing scaling_governor.

Now applied, thanks!