From patchwork Mon Apr 25 20:07:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matt Fleming X-Patchwork-Id: 66624 Delivered-To: patch@linaro.org Received: by 10.140.93.198 with SMTP id d64csp1234850qge; Mon, 25 Apr 2016 13:11:44 -0700 (PDT) X-Received: by 10.66.88.104 with SMTP id bf8mr51716089pab.129.1461615104599; Mon, 25 Apr 2016 13:11:44 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5si8643785pat.133.2016.04.25.13.11.44; Mon, 25 Apr 2016 13:11:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeblueprint-co-uk.20150623.gappssmtp.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965145AbcDYULl (ORCPT + 29 others); Mon, 25 Apr 2016 16:11:41 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38787 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965023AbcDYUIQ (ORCPT ); Mon, 25 Apr 2016 16:08:16 -0400 Received: by mail-wm0-f54.google.com with SMTP id u206so145168141wme.1 for ; Mon, 25 Apr 2016 13:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeblueprint-co-uk.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=EPeWVHm8x94HLrTLAHLGOBZri1NIvTSZPS1zF+P5UYE=; b=fKfzOy5P7NI/8PKsCL6MpNg1yCeIzELIVeCZhAv5FYa+FNT55A4PHJNsD4ljKhI0sk 2xAkOIkTeZ7EiPhGV+CLwi6apBcA5znAgZB6la8+cB8xjgOUZSO8SrG8e/okqdLcDTX9 AZZT00z05OCXEllTbYqtG7352K++itzJbc3EsHX4GRjZ0Ih5AdF/c83e1n21yOmoynX2 8UllkpllAOAJLRvjGR07LYS7tFmzsZbY1fXSVpRh6OJ7t1fi+IO/hcl+lh8c7vjL3z4d VojO/w+0wma+GIQy2YFKz6CwaA94pQCZ5Ok8YFogTVSWZLsm+lp6Y3+CE+6E8ZDO23Yf U4aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=EPeWVHm8x94HLrTLAHLGOBZri1NIvTSZPS1zF+P5UYE=; b=RKfTP5ooqLVijIapvd8U3kjD0cOtzsIl6Bs/aOLqDtG0oV9c3DrZnNiN3Bs1wi6FDH DtP2xeLRsIs4DE8UIZJYrqnOMLpl6uHwkXej1rKUntaYC/ah4mkqntg30YiMirHoTpeS hl24t0BOfW+tMi/JF+M6egouwta13Gk5LqR7HI0XjS+kvyONOWYiDCnqX6E9jBB0olnE OoKC33XhsU3QxTDk7yBiqXc5nScxN+gfcEaY2Dhrqx5UIGb80cOE+KUpXH9qvk2xamQ0 Oa4ZhGEp/8LMFzG/Rz12e4DcFZia+OAnao2vL6FQZW+cVCpwDx/FqUU0HfpMGAx9Ohk8 RqAw== X-Gm-Message-State: AOPr4FUPXeoKhI3DxXFpaY80mAqjaCFA7BeMyB7NJKfOGmjEeyfWc0W0IWIPG2UizR5XkQ== X-Received: by 10.28.129.22 with SMTP id c22mr13988932wmd.89.1461614894852; Mon, 25 Apr 2016 13:08:14 -0700 (PDT) Received: from localhost (bcdc58e5.skybroadband.com. [188.220.88.229]) by smtp.gmail.com with ESMTPSA id u192sm20365483wmd.11.2016.04.25.13.08.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Apr 2016 13:08:14 -0700 (PDT) From: Matt Fleming To: Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, Matt Fleming , Leif Lindholm , Will Deacon Subject: [PATCH 30/40] efi/arm-init: Reserve rather than unmap the memory map for ARM as well Date: Mon, 25 Apr 2016 21:07:02 +0100 Message-Id: <1461614832-17633-31-git-send-email-matt@codeblueprint.co.uk> X-Mailer: git-send-email 2.7.3 In-Reply-To: <1461614832-17633-1-git-send-email-matt@codeblueprint.co.uk> References: <1461614832-17633-1-git-send-email-matt@codeblueprint.co.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ard Biesheuvel Now that ARM has a fully functional memremap() implementation, there is no longer a need to remove the UEFI memory map from the linear mapping in order to be able to create a permanent mapping for it using generic code. So remove the 'IS_ENABLED(CONFIG_ARM)' conditional we added in commit 7cc8cbcf82d1 ("efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping"), and revert to using memblock_reserve() for both ARM and arm64 Signed-off-by: Ard Biesheuvel Cc: Will Deacon Cc: Leif Lindholm Signed-off-by: Matt Fleming --- drivers/firmware/efi/arm-init.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) -- 2.7.3 diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index 7a3318dd4319..ef90f0c4b70a 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -244,20 +244,9 @@ void __init efi_init(void) efi_memattr_init(); early_memunmap(efi.memmap.map, params.mmap_size); - if (IS_ENABLED(CONFIG_ARM)) { - /* - * ARM currently does not allow ioremap_cache() to be called on - * memory regions that are covered by struct page. So remove the - * UEFI memory map from the linear mapping. - */ - memblock_mark_nomap(params.mmap & PAGE_MASK, - PAGE_ALIGN(params.mmap_size + - (params.mmap & ~PAGE_MASK))); - } else { - memblock_reserve(params.mmap & PAGE_MASK, - PAGE_ALIGN(params.mmap_size + - (params.mmap & ~PAGE_MASK))); - } + memblock_reserve(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); init_screen_info(); }