[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.