On 13 April 2016 at 17:37, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> Instead of using ioremap_cache(), which is slightly inappropriate for
> mapping firmware tables, and is not even allowed on ARM for mapping
> regions that are covered by a struct page, use memremap(), which was
> invented for this purpose, and will also reuse the existing kernel
> direct mapping if the requested region is covered by it.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> ---
> drivers/firmware/efi/arm-runtime.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 98fe93a9813b..17ccf0a8787a 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -111,8 +111,7 @@ static int __init arm_enable_runtime_services(void)
>
> mapsize = efi.memmap.map_end - efi.memmap.map;
>
> - efi.memmap.map = (__force void *)ioremap_cache(efi.memmap.phys_map,
> - mapsize);
> + efi.memmap.map = memremap(efi.memmap.phys_map, mapsize, MEMREMAP_WB);
> if (!efi.memmap.map) {
> pr_err("Failed to remap EFI memory map\n");
> return -ENOMEM;
Actually, this patch does not depend on the ARM memremap changes being
merged: before those changes, memremap() unconditionally falls back to
ioremap_cache() for 'System RAM' so this patch is essentially a nop in
that case. This is guaranteed to work due to the fact that we [still]
use MEMBLOCK_NOMAP for mapping the memory map on ARM.
The memory attributes table and GOP changes do depend on it, however,
since the configuration tables it accesses are likely to be covered by
a struct page, in which case ARM disallows the ioremap_cache() (and
thus the use of memremap() until it is updated to deal with this
situation explicitly)
The other change that depends on it is dropping the MEMBLOCK_NOMAP for
ARM as well (as we did in the arm64 patch that is currently queued up
for v4.6-rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
