[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent
>>> On 16.01.16 at 06:01, <zhaoshenglong@xxxxxxxxxx> wrote: > --- a/xen/drivers/acpi/osl.c > +++ b/xen/drivers/acpi/osl.c > @@ -86,17 +86,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void) > void __iomem * > acpi_os_map_memory(acpi_physical_address phys, acpi_size size) > { > - if (system_state >= SYS_STATE_active) { > - mfn_t mfn = _mfn(PFN_DOWN(phys)); > - unsigned int offs = phys & (PAGE_SIZE - 1); > - > - /* The low first Mb is always mapped. */ > - if ( !((phys + size - 1) >> 20) ) > - return __va(phys); > - return __vmap(&mfn, PFN_UP(offs + size), 1, 1, > - PAGE_HYPERVISOR_NOCACHE) + offs; > - } > - return __acpi_map_table(phys, size); > + return arch_acpi_os_map_memory(phys, size); > } I'm quite sure I've said before that this goes too far: The __vmap() part and likely also the early-boot __acpi_map_table() one already are architecture independent and hence should stay. The factoring hence should only concern the first Mb handling and maybe the the mapping attributes passed to __vmap(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |