From patchwork Sat Feb 20 10:44:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 62452 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp263145lbl; Sat, 20 Feb 2016 02:44:25 -0800 (PST) X-Received: by 10.66.246.165 with SMTP id xx5mr24623242pac.87.1455965065293; Sat, 20 Feb 2016 02:44:25 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p83si23164844pfj.121.2016.02.20.02.44.25; Sat, 20 Feb 2016 02:44:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dkim=neutral (body hash did not verify) header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993760AbcBTKoY (ORCPT + 6 others); Sat, 20 Feb 2016 05:44:24 -0500 Received: from mail-io0-f170.google.com ([209.85.223.170]:34475 "EHLO mail-io0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993755AbcBTKoW (ORCPT ); Sat, 20 Feb 2016 05:44:22 -0500 Received: by mail-io0-f170.google.com with SMTP id 9so134896064iom.1 for ; Sat, 20 Feb 2016 02:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6A32U/3aAiZiaCa1lz6OnZFhcgRl26TTo5EAyqFD2T8=; b=JjJoMMQWIbPqfNqkaF5mR38z8u5Z5KDLyIMYnKDUsbUQpP1HZOS4EjpVtwF/U4/ade vr+EcpLyL+iKudzWucxk5Jf4ReGmfMPWdt8oZbMpXZt6J6UpFJqFnmsVh20HmgjeX3ue rGoRAkGKPysKfN6Z8actJiJEQpo4A448jxAhY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6A32U/3aAiZiaCa1lz6OnZFhcgRl26TTo5EAyqFD2T8=; b=IUM0NTSoN4+FClmw0QnXMz2GoeKSx3caSAgU/mV4QXWVTYMrjXvHKqwczgS7hLkbQ8 wmd/szrajFbQ8AJTRmGGwaATOP3f6VapScGaMUcZWB/LtvElhVWipsM2VtWi4OKHRXw6 2k6RQA4U7gcOw40p+ey3HctzsSxSrqeS+TyiqYVQD6jjAlYu7/68nUCsX3EN89Cri7uY ssfbfdyDyKWyaRx2ONErLMxr4/fghWtMwxDnbmSWYlz5HUyVNnkDElLZv+lZwYf07DZP zxRg9lNpkjQUdPKnfBC4Vm10naD6DIo2UlpBtLlNdqMesyy8LlWVE5H7cshxnZLYj1AU OM5A== X-Gm-Message-State: AG10YOSmm8fi8Vk1SA/vWIOdAPWhVw5ToNmEDhcQAYdCbf2UNJNKuYSwFRl9L/RqESZd8DzgYAHT8Md1hRpqcFIW MIME-Version: 1.0 X-Received: by 10.107.135.20 with SMTP id j20mr21951880iod.56.1455965062239; Sat, 20 Feb 2016 02:44:22 -0800 (PST) Received: by 10.36.29.6 with HTTP; Sat, 20 Feb 2016 02:44:22 -0800 (PST) In-Reply-To: <20160220103959.GC4914@rric.localdomain> References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com> <20160220103959.GC4914@rric.localdomain> Date: Sat, 20 Feb 2016 11:44:22 +0100 Message-ID: Subject: Re: [PATCH v11 00/10] arm64, numa: Add numa support for arm64 platforms From: Ard Biesheuvel To: Robert Richter Cc: David Daney , Grant Likely , Rob Herring , Will Deacon , "linux-arm-kernel@lists.infradead.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , Frank Rowand , Catalin Marinas , Matt Fleming , "linux-efi@vger.kernel.org" , Ganapatrao Kulkarni , "linux-kernel@vger.kernel.org" , David Daney Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 20 February 2016 at 11:39, Robert Richter wrote: > On 20.02.16 09:20:05, Ard Biesheuvel wrote: >> On 20 February 2016 at 02:13, David Daney wrote: >> > From: David Daney >> > >> > v11: >> > - Dropped cleanup patches for other architectures, they will be >> > submitted as a separate set after more testing. >> > >> > - Added patch set from Ard Biesheuvel that are needed to make >> > the whole thing actually work. Previously this was a >> > separate set. >> > >> >> This series is out of date, unfortunately. The EFI init code is now >> (as of v4.5-rc1) shared between ARM and arm64, which means that any >> changes you make must be made on both sides. This applies to the split >> between parsing the EFI dt nodes and performing the actual EFI init, >> but also to the early_init_dt_add_memory_arch() changes. I am happy to >> have a go at this, but first I need a clear statement from whoever >> maintains that area that keeping memory nodes *just* for the >> annotations (and otherwise ignore them) is the way forward (Rob? >> Grant?) > > Wasn't there the approach to check for consistency between efi tables > and devicetree? Thus, DT is actually not ignored but rather checked if > it is in sync with efi tables. > I proposed such an approach for the /reserved-memory node, but not for the memory nodes themselves. But thinking about this a bit more, I think we can replace the whole 6 piece series with the following patch (apologies for the mangled whitespace). The reason is that, if we decide to keep the memory nodes, we might just as well parse them as usual (and use generic code to spot any problems etc), and just discard the regions it describes. This completely solves the ARM vs arm64 problem. ---------8<-------------- Subject: [PATCH] efi: ARM/arm64: ignore DT memory nodes instead of removing them There are two problems with the UEFI stub DT memory node removal routine: - it deletes nodes as it traverses the tree, which happens to work but is not supported, as deletion invalidates the node iterator; - deleting memory nodes entirely may discard annotations in the form of additional properties on the nodes. Since the discovery of DT memory nodes occurs strictly before the UEFI init sequence, we can simply clear the memblock memory table before parsing the UEFI memory map. This way, it is no longer necessary to remove the nodes, so we can remove that logic from the stub as well. Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/arm-init.c | 8 +++++++ drivers/firmware/efi/libstub/fdt.c | 24 +------------------- 2 files changed, 9 insertions(+), 23 deletions(-) u64 fdt_val64; @@ -54,28 +54,6 @@ goto fdt_set_fail; /* - * Delete any memory nodes present. We must delete nodes which - * early_init_dt_scan_memory may try to use. - */ - prev = 0; - for (;;) { - const char *type; - int len; - - node = fdt_next_node(fdt, prev, NULL); - if (node < 0) - break; - - type = fdt_getprop(fdt, node, "device_type", &len); - if (type && strncmp(type, "memory", len) == 0) { - fdt_del_node(fdt, node); - continue; - } - - prev = node; - } - - /* * Delete all memory reserve map entries. When booting via UEFI, * kernel will use the UEFI memory map to find reserved regions. */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index 9e15d571b53c..40c9d8596d69 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -143,6 +143,14 @@ static __init void reserve_regions(void) if (efi_enabled(EFI_DBG)) pr_info("Processing EFI memory map:\n"); + /* + * Discard memblocks discovered so far: if there are any at this + * point, they originate from memory nodes in the DT, and UEFI + * uses its own memory map instead. + */ + memblock_dump_all(); + memblock_remove(0, ULLONG_MAX); + for_each_efi_memory_desc(&memmap, md) { paddr = md->phys_addr; npages = md->num_pages; diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 6dba78aef337..e58abfa953cc 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt, unsigned long map_size, unsigned long desc_size, u32 desc_ver) { - int node, prev, num_rsv; + int node, num_rsv; int status; u32 fdt_val32;