Re: [Xen-devel] [PATCH 6/9] x86/intel_pstate: the main boby of the intel_pstate driver

["Wang, Wei W" <wei.w.wang@xxxxxxxxx>]

On 26/04/2015 01:33, Julien Grall wrote
Hi Julien,

> On 26/04/2015 05:32, Wang, Wei W wrote:
> > On 24/04/2015 20:57, Julien Grall wrote
> >> On 23/04/2016 18:58, Wei Wang wrote:
> >>> diff --git a/xen/include/acpi/cpufreq/processor_perf.h
> >>> b/xen/include/acpi/cpufreq/processor_perf.h
> >>> index d8a1ba6..ebff11d 100644
> >>> --- a/xen/include/acpi/cpufreq/processor_perf.h
> >>> +++ b/xen/include/acpi/cpufreq/processor_perf.h
> >>> @@ -7,6 +7,7 @@
> >>>
> >>>    #define XEN_PX_INIT 0x80000000
> >>>
> >>> +int intel_pstate_init(void);
> >>
> >> The intel pstate driver is x86 specific. Although xen/include/acpi
> >> contains common headers for common code.
> >
> > Thanks for your comments. But I saw "int powernow_cpufreq_init(void);"
> is put there.
> 
> FWIW, this prototype doesn't have any implementation even on x86.
> 
> While currently some drivers (such as the x86 powernow) may define
> prototype in the common header. This is wrong, the common code should
> not be able to call those functions.
> 
> There is an ongoing support on ACPI for ARM (an RFC has been sent a couple
> of months ago). Adding new x86 prototype in this directory complicate the
> splitting. Please help us to at least avoid adding new
> x86 specific prototype/code in the common code when it's possible.
> 
> We will take care of moving the current x86 prototype/code in the arch-
> specific directories.
> 
> Although, I'm not a maintainer. They may have a different opinion on this
> point.

Sure. I will do it if maintainers don't have a different opinion.

Best,
Wei

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel