On Mon, 2015-07-27 at 10:45 +0100, Will Deacon wrote: > > That bit's fine. The weird bit is: > > pgprot_t prot; > > prot = efi_mem_attributes(addr); > > Since that's putting the arch-independent format into the pg_prot.
Oops, missed that. Yeah that's funky. > > I don't see how you can do that any other way than by using pgprot_t. > > > > Really, the problem here is that ioremap_page_caller() has no notion of > > "map this range in a firmware-compatible manner". If we could do, for > > example, > > > > ioremap_page_range(vaddr, vend, paddr, PAGE_FW_COMPAT); > > > > that would allow the innards of the arch-ioremap to figure out exactly > > how to map this range so that the firmware could access it coherently. > > > > I suggested this previously but it didn't gain any traction. > > Yeah, or just ioremap_efi. > > </me runs away> Someone beat you to it ;-) arch/x86/include/asm/efi.h:#define efi_ioremap(addr, size, type, attr) ioremap_cache(addr, size) arch/x86/include/asm/efi.h:extern void __iomem *__init efi_ioremap(unsigned long addr, unsigned long size, arch/x86/platform/efi/efi.c: va = efi_ioremap(md->phys_addr, size, arch/x86/platform/efi/efi_64.c:void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size, arch/x86/platform/efi/efi_64.c: efi_ioremap(top, size - (top - phys_addr), type, attribute); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
