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

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

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.

Thanks,
Rafael