[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 22/22] xen/arm64: Add ACPI support
>>> On 17.03.16 at 14:10, <zhaoshenglong@xxxxxxxxxx> wrote: > > On 2016/3/17 19:31, Jan Beulich wrote: >>>>> On 17.03.16 at 12:03, <zhaoshenglong@xxxxxxxxxx> wrote: >>> > On 2016/3/17 18:52, Jan Beulich wrote: >>>>>>> >>>>> On 17.03.16 at 10:41, <zhaoshenglong@xxxxxxxxxx> wrote: >>>>>> >>> > --- a/xen/include/asm-arm/config.h >>>>>> >>> > +++ b/xen/include/asm-arm/config.h >>>>>> >>> > @@ -31,6 +31,10 @@ >>>>>> >>> > >>>>>> >>> > #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */ >>>>>> >>> > >>>>>> >>> > +#ifdef CONFIG_ACPI >>>>>> >>> > +#define CONFIG_ACPI_BOOT 1 >>>>>> >>> > +#endif >>>> >> Do we think that ACPI without ACPI_BOOT is useful for anything? >>>> >> If not, I think we should just get rid of the latter in common code >>>> >> (x86 could be cleaned up separately), and hence ARM wouldn't >>>> >> have a need for this ugliness. If however we do, then this should >>>> >> be switched to Kconfig (at once on x86 then). >>> > I think we could replace CONFIG_ACPI_BOOT with CONFIG_ACPI. Maybe we >>> > could clean up them on top this of patch. >> Cleaning up the sole common code use should be done as a prereq, >> or even inside this patch. Doing such cleanup on top is a bad idea: >> We should aim at not introducing any further CONFIG_* #define-s >> in headers, now that we have the Kconfig machinery in place. > Ok, so it's fine to you that replace CONFIG_ACPI_BOOT with CONFIG_ACPI > in common and x86 codes, right? If so, I'll add a patch to that before > thia patch. Yes - I certainly welcome if you want to clean up x86 at once. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |