[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 04/10] acpi: Don't do traditional BIOS table scan for ARM64




On 2016/1/18 21:29, Jan Beulich wrote:
>>>> On 16.01.16 at 06:01, <zhaoshenglong@xxxxxxxxxx> wrote:
>> > --- a/xen/drivers/acpi/tables/tbxfroot.c
>> > +++ b/xen/drivers/acpi/tables/tbxfroot.c
>> > @@ -49,6 +49,12 @@
>> >  #define _COMPONENT          ACPI_TABLES
>> >  ACPI_MODULE_NAME("tbxfroot")
>> >  
>> > +#ifdef CONFIG_ARM
>> > +acpi_status __init acpi_find_root_pointer(acpi_native_uint * 
>> > table_address)
>> > +{
>> > +  return_ACPI_STATUS(AE_NOT_FOUND);
>> > +}
>> > +#else
>> >  /* Local prototypes */
>> >  static u8 *acpi_tb_scan_memory_for_rsdp(u8 * start_address, u32 length);
>> >  
>> > @@ -271,3 +277,4 @@ static u8 *__init acpi_tb_scan_memory_for_rsdp(u8 * 
>> > start_address, u32 length)
>> >                      start_address));
>> >    return_PTR(NULL);
>> >  }
>> > +#endif
> You modify ACPI CA code here, which should be avoided if at all
> possible. Why don't you simply port over Linux'es solution (which
> changes osl.c instead), the more that now we have Linux-like
> Kconfig?
Of course I can and I suggested this way at v3 but ...
Hope this your final suggestion. Thanks in advance!

-- 
Shannon


_______________________________________________
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®.