On 12/06/2015 19:14, Julien Grall wrote: > On 11/06/2015 23:03, Wang, Wei W wrote: > > On 11/06/2015 22:02, Julien Grall wrote: > >> On 11/06/2015 04:31, Wei Wang wrote: > >>> - list_for_each(pos, &cpufreq_governor_list) > >>> + if (policy->policy) > >> > >> What if another cpufreq decides to use policy->policy? > > > > What is "another cpufreq"? The "policy" is per-CPU struct. > > I mean another cpufreq driver. Correct me if I'm wrong but from the name > policy is not intel pstate specific. That means that a new cpufreq driver can > decide to use the field his own purpose..
We actually want it be intel_pstate specific. If maintainers agree, I think renaming it to intel_pstate_policy is a good option. > > > > + gov_num = INTEL_PSTATE_INTERNAL_GOV_NUM; > >> > >> Why not using cpufreq_governor_list? > > This should not be a problem after renaming "->policy" to be "->intel_pstate_policy". Best, Wei > > That's used by the old driver. We are not going through that old governor > layer. > > This is common code, it's used by different cpufreq driver for both x86 and > ARM (not yet supported). We should not relying on any other cpufreq driver > won't use the field policy. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel