From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fleming Subject: Re: [PATCH 2/2] efi/arm*: use memremap() to create the persistent memmap mapping Date: Thu, 14 Apr 2016 13:23:05 +0100 Message-ID: <20160414122305.GO2829@codeblueprint.co.uk> References: <1460561873-27756-1-git-send-email-ard.biesheuvel@linaro.org> <1460561873-27756-2-git-send-email-ard.biesheuvel@linaro.org> 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" List-Id: linux-efi@vger.kernel.org On Thu, 14 Apr, at 10:43:45AM, Ard Biesheuvel wrote: > > 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. OK, these two look good to me, so I'm going to queue them up in 'next' chronologically before your EFI Memory Attributes table patches. > 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) Noted. Thanks Ard.