From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0DC9C433EF for ; Wed, 18 May 2022 17:54:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235424AbiERRyl (ORCPT ); Wed, 18 May 2022 13:54:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241140AbiERRyk (ORCPT ); Wed, 18 May 2022 13:54:40 -0400 Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04F6321A961 for ; Wed, 18 May 2022 10:54:40 -0700 (PDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-2f863469afbso33517557b3.0 for ; Wed, 18 May 2022 10:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wAFhBNGkOYqIauqmAMb6moZVrSw8HOJBfdYpqesZq6Y=; b=vs9ButGw7170Q/jEs+fO1lQveZiTXXsgwXYCkgtgQO09RlQztc3/GxtOitWuHeXu2+ /m5UIMGqa+jiWxNGKo3H1/D9oMvC/sYdhfX+LOTuCNJVTY8nvtyyodAe7NB4yVZ6tK0+ c/SdQO3Y6jVZmVJAXeNoY/5fs3sDRwtH/fP80XkLq3cUjQ/Rc4dX5GTWC9+tzMSg48sW Flac7WAF1NQggHKxkWDJIJ6Vh4LASxdp06hGbSQOl1y08Guq5Y61mXm47is1jS7G/Wjl EixXBi++mSL7Xffq0yM4KMyLbCrYwJueODALS+TYjh7Z5o0zOVDvtAixJzlR7m41G89u Jdtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wAFhBNGkOYqIauqmAMb6moZVrSw8HOJBfdYpqesZq6Y=; b=p+wM8qh3TckSObU5ZwFFopU8IypQ/HvaviHiJfHr0cVtCRH/9wHwpj7AM62Fz4SJFQ 8c5E/U0qS+64zPi2NHhjEzMjDYFEiQ+kNYf0mA1YrKnLXiUA3zWsCYL1y+hahxQpakFP NyDWKAMki2Z/eKglBzLjg6sOQOUuvXh2UiGfTwUi1uS3TiQ28kvmwrXnVZGvboX0qQkU OBKdH+ay6l1jVdg05j3UXB6ng/2vTndGZad0KVw9IlysVlGPVXozPrG4pWPAv7irE/5X dxylGziSHJX2DS3EOZUqIjKTMYmIOMnr7aVHjqacVd9HSlS4KxZQ5M6KAKa18JUfKVVV PPgA== X-Gm-Message-State: AOAM533ctPiE+Siogf78K3gjJB0JA26PBk9QuvEnuKA+v1pPzogE2XWU JmnM+92XwG2ly3xbkS14wP88HeNsLWxIauBMTJMR3KMiVbGiRg== X-Google-Smtp-Source: ABdhPJxcdiytOucNPQKz7tmCfcmD4wZOseejv1XT7mflreTeZKYT19r/h5oY+Ga1GZ2fAhunKyzGPlKDPrqsdZg1R/o= X-Received: by 2002:a81:1dcf:0:b0:2fa:d094:14ff with SMTP id d198-20020a811dcf000000b002fad09414ffmr642224ywd.10.1652896479286; Wed, 18 May 2022 10:54:39 -0700 (PDT) MIME-Version: 1.0 References: <20220517101410.3493781-1-andre.przywara@arm.com> <20220517153444.GA1057027-robh@kernel.org> <20220518165421.GF3302100-robh@kernel.org> In-Reply-To: <20220518165421.GF3302100-robh@kernel.org> From: Peter Maydell Date: Wed, 18 May 2022 18:54:28 +0100 Message-ID: Subject: Re: [PATCH] of/fdt: Ignore disabled memory nodes To: Rob Herring Cc: Andre Przywara , Frank Rowand , devicetree@vger.kernel.org, linux-arm-kernel , "linux-kernel@vger.kernel.org" , Ross Burton , Ard Biesheuvel , Catalin Marinas , Will Deacon , Russell King Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, 18 May 2022 at 17:54, Rob Herring wrote: > > On Tue, May 17, 2022 at 08:19:47PM +0100, Peter Maydell wrote: > > We generate the DTB with libfdt, so source-only information > > isn't something we can put in, I think. (The quoted DT fragment > > in this patch's commit message is the result of decompiling > > the runtime generated DT binary blob with dtc.) > > Given the runtime aspect with overlays, it's conceivable that libfdt > could support setting labels some day and then dts output maintaining > them. > > We could also consider a standard node name such as 'secure-memory'. > It's a whole can of worms though on how secure vs. non-secure memory > (and other things) are represented. Mmm. We put in the very basic parts years ago in Documentation/devicetree/bindings/arm/secure.txt which is (and has remained) generally sufficient for the QEMU->Trusted Firmware-> maybe uboot->Linux stack, which is pretty much the only use case I think. (My intention when we wrote that up was that memory that's S-only would be indicated the same way as S-only devices, with the secure-status and status properties.) > > Are we just stuck with what we have for historical reasons ? > > Yes. If we were designing this, we'd probably have 'compatible = > "memory"'. We're likely just stuck with things how they are. Mostly node > names haven't been an ABI and we're just trying to be consistent in > naming and use of unit-addresses. So, do you think it's worthwhile/a good idea for me to rename the DT node that QEMU is currently calling "secmem" to be "memory" ? My default is "leave it as it is", for economy of effort reasons :-) -- but it's an easy enough change to make. Though EDK2's dtb reading code just looks for the first "memory" node and assumes it's the big one, so changing the node name would make us reliant on the order of the two nodes in the DTB unless we fixed EDK2 (which we should probably do anyway, tbh). thanks -- PMM