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 5B20EC433F5 for ; Tue, 17 May 2022 19:20:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352661AbiEQTUD (ORCPT ); Tue, 17 May 2022 15:20:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348534AbiEQTUA (ORCPT ); Tue, 17 May 2022 15:20:00 -0400 Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9045427C0 for ; Tue, 17 May 2022 12:19:59 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2f83983782fso1401987b3.6 for ; Tue, 17 May 2022 12:19:59 -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=2eoz2FUrFUdjGA8OgTVmDbdUGsT/gwE/rSjYW1YpgfY=; b=ihKzkeBc+Xb/IoVLp0fS7Sr0sxJjfhS1Yqo/VO13B+NX8DQrnuSiCBe9gpENlnq01r ebTJJP3C0S0avc8TXWvc01/zvZ+tw/+jgS+5d1VY5zDY06zNOqru2fXQB/ItakDrQ3ow cne2MBsJ8hEm/+vnBcY2LiW+eDmS55w+G7kSUwkDfuOZIpsvJnKs3dgrdsrO1CJhTKdt wER5VlGEGFR3K2VU0nTgQ3rtlR/EcIsNeu2lJeDOKnvMxO3X0Vvc+WZJJyzAOO9lK73f LTyvMHRtNq7EsyvwSLf0yuIiMNguhyDeI+NwpWwKslbnOs4wH+DfNICmm/g3jHORiZCB VaxQ== 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=2eoz2FUrFUdjGA8OgTVmDbdUGsT/gwE/rSjYW1YpgfY=; b=xcYLgWanMvbYtBx2lHrSVbAnta1QUbd81c28uO+g75COs32yo60uo9/rCXup+Y7tZH Sfx5S4NQFp/OM5bMj9QgtGbN20mSFYvy46iq1cnEt8C2zVk5McKUq3Mru8EEqGIM+0gM NBdBVcC6dtapAH3idvfOsJkuQHURLzAVdkQgl6WD5W4InOs1ym2NJqTjt6haxY2j31AF lh+mvCesnAIm8I6H5XcWao6ewttFilEQoav5rCLxvvZDxN1jO5SDmv/ISE4uB3V+qK2p SiVTCk31IDbDQVySG3wYTK5c+WKjC6RDLrW/UfY1dqzGSP3wuCpUAxn6yaDtDKax7vA9 CIkA== X-Gm-Message-State: AOAM533NJ7NxaWFGhn8VeRRhXdi9jlL5Wt+Fh3piNV6v2fGjdcEWoBsU xZOmmsLF1ulvPcOBW3hiXNyMr6UGiBG+wbKD41l9Ng== X-Google-Smtp-Source: ABdhPJy3AGEf/jdtpQoDRNYkU8ty9svrivAgusrhZV72ZWDTtuhp26qWGxVrqU1OZm5SU1BIJUJ5zWr+riqgYean1io= X-Received: by 2002:a81:6904:0:b0:2fe:e670:318a with SMTP id e4-20020a816904000000b002fee670318amr14914838ywc.329.1652815198932; Tue, 17 May 2022 12:19:58 -0700 (PDT) MIME-Version: 1.0 References: <20220517101410.3493781-1-andre.przywara@arm.com> <20220517153444.GA1057027-robh@kernel.org> In-Reply-To: From: Peter Maydell Date: Tue, 17 May 2022 20:19:47 +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: linux-kernel@vger.kernel.org On Tue, 17 May 2022 at 18:48, Rob Herring wrote: > > On Tue, May 17, 2022 at 11:54 AM Peter Maydell wrote: > > > > On Tue, 17 May 2022 at 16:34, Rob Herring wrote: > > > > > > On Tue, May 17, 2022 at 11:14:10AM +0100, Andre Przywara wrote: > > > > When we boot a machine using a devicetree, the generic DT code goes > > > > through all nodes with a 'device_type = "memory"' property, and collects > > > > all memory banks mentioned there. However it does not check for the > > > > status property, so any nodes which are explicitly "disabled" will still > > > > be added as a memblock. > > > > This ends up badly for QEMU, when booting with secure firmware on > > > > arm/arm64 machines, because QEMU adds a node describing secure-only > > > > memory: > > > > =================== > > > > secram@e000000 { > > > > > > BTW, 'memory' is the correct node name. > > > > We already have a 'memory' node, which is for the NS > > memory. This one's for the secure-only RAM block, > > which is why I gave it a name that hopefully helps in > > spotting that when a human is reading the DT. > > You can do: secram: memory@e000000 { > > Where 'secram' is only a source level label until overlays come into > the picture. 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.) > > I'm not really sure to what extent node names in device trees are > > "this is just an identifying textual label" and to what extent > > they are "this is really ABI and you need to follow the standard", > > though -- nothing in practice seems to care what they are, > > suggesting the "textual label" theory, but some bits of tooling > > complain if you do things like forget the address value or use the > > same address for two different nodes, suggesting the "really ABI" > > theory. > > Node names are supposed to follow the class of device and there's a > list of established names in the spec. > > Sometimes it's ABI and sometimes not. Much of it is just good hygiene. > memory nodes are also special because 'device_type' is used to > identify them, but device_type is generally deprecated for FDT as its > meaning in OpenFirmware doesn't apply (it defines what callable > methods exist). We could use the nodename (without unit address) > instead, but that would fail in some cases as other names have been > used. This seems kind of odd to me as a design, compared to "have the node have a property that says what it is and let the name of the node just be, well, its name" (especially since 'device_type' and 'compatible' look an awful lot like "this is the property that tells you what this node actually is".) Are we just stuck with what we have for historical reasons ? -- PMM 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F2737C433F5 for ; Tue, 17 May 2022 19:21:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mfUg1preAL51ii6X6r6nw6iyvgnE4ySCe6aaZYFKF5o=; b=OVAXDMhpyB7/SI 2nDu2NN0gm4TdN8YlO5D6F6Ed1wF+XuLo3F3WbpJ3u3Jhy8UAskLgNL634hcJ90EjPisVtRV7PUFK tP/Z7FwCsEuwB7m6f7spHNfm+MLhxFnm4CzeLnXfHJHbiPr39SB1bu2AZc+vZdZMkrYpEHQBnmakj /McwR/tcyHkNy4nGNC77WnIoh9io1OADeK9nTJ/ur9GseG3QJTsJ3tu9GxxcctrsHa+cXq+GF640M 3QYJuT/JRGd/YEM7e8X7XBojfGxB9aSqgSK85CHIt85acIiDb5YhSjI1r1Vd7DYNc5BL1yqWA3KwB ZTKRl0sagQAntw8idRiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr2jj-00FadP-P4; Tue, 17 May 2022 19:20:03 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr2jg-00FacU-S4 for linux-arm-kernel@lists.infradead.org; Tue, 17 May 2022 19:20:02 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-2ff155c239bso1634427b3.2 for ; Tue, 17 May 2022 12:19:59 -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=2eoz2FUrFUdjGA8OgTVmDbdUGsT/gwE/rSjYW1YpgfY=; b=ihKzkeBc+Xb/IoVLp0fS7Sr0sxJjfhS1Yqo/VO13B+NX8DQrnuSiCBe9gpENlnq01r ebTJJP3C0S0avc8TXWvc01/zvZ+tw/+jgS+5d1VY5zDY06zNOqru2fXQB/ItakDrQ3ow cne2MBsJ8hEm/+vnBcY2LiW+eDmS55w+G7kSUwkDfuOZIpsvJnKs3dgrdsrO1CJhTKdt wER5VlGEGFR3K2VU0nTgQ3rtlR/EcIsNeu2lJeDOKnvMxO3X0Vvc+WZJJyzAOO9lK73f LTyvMHRtNq7EsyvwSLf0yuIiMNguhyDeI+NwpWwKslbnOs4wH+DfNICmm/g3jHORiZCB VaxQ== 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=2eoz2FUrFUdjGA8OgTVmDbdUGsT/gwE/rSjYW1YpgfY=; b=a36L7WyQ0O/wTaphUzIll0MH5gvu8SH2IFk3Ij/Vt8vddXRcz3PyfGb073H3XFsHzT WiC4yBgLPKvkjDSxGEXIjkiwp7uUVhcap+FgD+Q3M9H30ZrOPRnBI/dvLFr15zZHOFR5 y5KRFzqmyNAOxbstkSZ9iZr7TikokKh70hujRpqwcC5hbVJLtkA1uB1HYcXOKTjTsebX ysMGncejhfAq7F3EqIjBkz7Uh+Xvjh4zOkSmpYdUInmE7aysccO7vK6WJYCl+O32Hf5q VnTSe5AZovMvE2fMIJ9Bti64Bk28Ij8qnNepFknoz0wImUpFf1u3HKNtmapptjSN2B+M LkPg== X-Gm-Message-State: AOAM533rdAIhBos9YhY5Per9HPaE8F1SZYwVz6wSaAgEXhdheg9kNnq7 LDlsnXrqBF9t0cy/Zr0uSP7b7mvWz+ByYWz+8lTCZQ== X-Google-Smtp-Source: ABdhPJy3AGEf/jdtpQoDRNYkU8ty9svrivAgusrhZV72ZWDTtuhp26qWGxVrqU1OZm5SU1BIJUJ5zWr+riqgYean1io= X-Received: by 2002:a81:6904:0:b0:2fe:e670:318a with SMTP id e4-20020a816904000000b002fee670318amr14914838ywc.329.1652815198932; Tue, 17 May 2022 12:19:58 -0700 (PDT) MIME-Version: 1.0 References: <20220517101410.3493781-1-andre.przywara@arm.com> <20220517153444.GA1057027-robh@kernel.org> In-Reply-To: From: Peter Maydell Date: Tue, 17 May 2022 20:19:47 +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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220517_122000_944187_E8A018EF X-CRM114-Status: GOOD ( 33.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 17 May 2022 at 18:48, Rob Herring wrote: > > On Tue, May 17, 2022 at 11:54 AM Peter Maydell wrote: > > > > On Tue, 17 May 2022 at 16:34, Rob Herring wrote: > > > > > > On Tue, May 17, 2022 at 11:14:10AM +0100, Andre Przywara wrote: > > > > When we boot a machine using a devicetree, the generic DT code goes > > > > through all nodes with a 'device_type = "memory"' property, and collects > > > > all memory banks mentioned there. However it does not check for the > > > > status property, so any nodes which are explicitly "disabled" will still > > > > be added as a memblock. > > > > This ends up badly for QEMU, when booting with secure firmware on > > > > arm/arm64 machines, because QEMU adds a node describing secure-only > > > > memory: > > > > =================== > > > > secram@e000000 { > > > > > > BTW, 'memory' is the correct node name. > > > > We already have a 'memory' node, which is for the NS > > memory. This one's for the secure-only RAM block, > > which is why I gave it a name that hopefully helps in > > spotting that when a human is reading the DT. > > You can do: secram: memory@e000000 { > > Where 'secram' is only a source level label until overlays come into > the picture. 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.) > > I'm not really sure to what extent node names in device trees are > > "this is just an identifying textual label" and to what extent > > they are "this is really ABI and you need to follow the standard", > > though -- nothing in practice seems to care what they are, > > suggesting the "textual label" theory, but some bits of tooling > > complain if you do things like forget the address value or use the > > same address for two different nodes, suggesting the "really ABI" > > theory. > > Node names are supposed to follow the class of device and there's a > list of established names in the spec. > > Sometimes it's ABI and sometimes not. Much of it is just good hygiene. > memory nodes are also special because 'device_type' is used to > identify them, but device_type is generally deprecated for FDT as its > meaning in OpenFirmware doesn't apply (it defines what callable > methods exist). We could use the nodename (without unit address) > instead, but that would fail in some cases as other names have been > used. This seems kind of odd to me as a design, compared to "have the node have a property that says what it is and let the name of the node just be, well, its name" (especially since 'device_type' and 'compatible' look an awful lot like "this is the property that tells you what this node actually is".) Are we just stuck with what we have for historical reasons ? -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel