[Public]
> -----Original Message-----
> From: Jan Beulich <jbeul...@suse.com>
> Sent: Thursday, July 24, 2025 10:09 PM
> To: Penny, Zheng <penny.zh...@amd.com>
> Cc: Huang, Ray <ray.hu...@amd.com>; Anthony PERARD
> <anthony.per...@vates.tech>; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v6 18/19] xen/cpufreq: bypass governor-related para for
> amd-
> cppc-epp
>
> On 11.07.2025 05:51, Penny Zheng wrote:
> > --- a/xen/drivers/cpufreq/cpufreq.c
> > +++ b/xen/drivers/cpufreq/cpufreq.c
> > @@ -968,3 +968,9 @@ bool cpufreq_in_cppc_passive_mode(unsigned int cpuid)
> > return processor_pminfo[cpuid]->init & XEN_CPPC_INIT &&
> > cpufreq_driver.target;
> > }
> > +
> > +bool cpufreq_is_governorless(unsigned int cpuid) {
> > + return processor_pminfo[cpuid]->init && (hwp_active() ||
> > +
> > +cpufreq_driver.setpolicy); }
>
> The function, by its name, is seemingly generic, yet its implementation is
> tailored to
> the HWP and CPPC drivers. I think such needs calling out in a comment.
>
> Seeing the XEN_CPPC_INIT check in context, I also wonder why here you check
> for ->init just being non-zero.
>
Checking ->init being non-zero is to ensure that cpufreq core is initialized
successfully, no matter Px mode or CPPC mode.
As non-zero cpufreq_driver.setpolicy callback could only verify that registered
cpufreq driver is governorless.
Maybe I shall add comments to explain
> Jan
