[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 05/62] acpi: Don't do traditional BIOS table scan for ARM64
>>> On 24.11.15 at 04:39, <zhaoshenglong@xxxxxxxxxx> wrote: > On 2015/11/23 19:35, Jan Beulich wrote: >>>>> On 23.11.15 at 12:24, <stefano.stabellini@xxxxxxxxxxxxx> wrote: >>> On Tue, 17 Nov 2015, shannon.zhao@xxxxxxxxxx wrote: >>>> --- a/xen/drivers/acpi/osl.c >>>> +++ b/xen/drivers/acpi/osl.c >>>> @@ -78,7 +78,9 @@ acpi_physical_address __init >>>> acpi_os_get_root_pointer(void) >>>> } else { >>>> acpi_physical_address pa = 0; >>>> >>>> + #ifdef CONFIG_X86 >>>> acpi_find_root_pointer(&pa); >>>> + #endif >>>> return pa; >>>> } >>> >>> I think it might be best to error out earlier if acpi and !efi_enabled >>> on arm and arm64. If we do that we'll never enter this "else". >>> >>> If acpi_find_root_pointer doesn't build on arm, we should move it to an >>> x86 specific location, such as xen/arch/x86/efi. >> >> No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead >> the function itself should be stubbed out to do nothing on ARM. (And >> of course also the #ifdef placement is rather odd). >> > How about adding a new CONFIG_ACPI_LEGACY_TABLES_LOOKUP like Linux > kernel for x86? Unless you know of an architecture other than x86 potentially needing this, I think this would go too far. Plus the suggested name would imply "old style" lookup only, whereas per-arch customization also allows for other "modern" (or simply "alternative") mechanisms to be used. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |