From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fleming Subject: Re: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT table in memory Date: Thu, 18 Feb 2016 13:43:24 +0000 Message-ID: <20160218134324.GG2651@codeblueprint.co.uk> References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org> <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org> <20160218104407.GC2651@codeblueprint.co.uk> <20160218132824.GE2651@codeblueprint.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ard Biesheuvel Cc: "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Leif Lindholm , Mark Rutland , Peter Jones , "Baicar, Tyler" , Dave Young List-Id: linux-efi@vger.kernel.org On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote: > On 18 February 2016 at 14:28, Matt Fleming wrote: > > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote: > >> On 18 February 2016 at 11:44, Matt Fleming wrote: > >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote: > >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like > >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged > >> >> as an error if the memory region being mapped is also covered by the > >> >> linear mapping, since that would lead to aliases with conflicting > >> >> cacheability attributes. > >> >> > >> >> Since what we are dealing with is not an I/O region with side effects, > >> >> using ioremap() here is arguably incorrect anyway, so let's replace > >> >> it with memremap instead. Also add a missing unmap on the success path, > >> >> and drop a memblock_remove() call which does not belong here, this far > >> >> into the boot sequence. > >> >> > >> >> Cc: Peter Jones > >> >> Signed-off-by: Ard Biesheuvel > >> >> --- > >> >> drivers/firmware/efi/esrt.c | 16 ++++++++-------- > >> >> 1 file changed, 8 insertions(+), 8 deletions(-) > >> >> > >> > > >> > [...] > >> > > >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void) > >> >> if (error) > >> >> goto err_cleanup_list; > >> >> > >> >> - memblock_remove(esrt_data, esrt_data_size); > >> >> - > >> >> pr_debug("esrt-sysfs: loaded.\n"); > >> >> > >> >> return 0; > >> > > >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()? > >> > The original ESRT region is still reserved at this point, so we should > >> > do our best to release it to the page allocator. > >> > >> I'd rather we keep it reserved. That way, the config table entry still > >> points to something valid, which could be useful for kexec(), I think? > >> At least, that is how I intended to handle config tables on ARM ... > > > > If we're going to reserve it why do we need to copy the data out at > > all in esrt_sysfs_init()? > > Excellent question. I don't think there is any point to doing that. ... Unless the data is contained in an EFI Boot Services region ;-) Peter?