From: Rob Herring <robh@kernel.org> To: Peter Maydell <peter.maydell@linaro.org> Cc: Andre Przywara <andre.przywara@arm.com>, Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Ross Burton <ross.burton@arm.com>, Ard Biesheuvel <ardb@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Russell King <linux@armlinux.org.uk> Subject: Re: [PATCH] of/fdt: Ignore disabled memory nodes Date: Tue, 17 May 2022 12:47:56 -0500 [thread overview] Message-ID: <CAL_JsqLRvEn2E7cpTzQJRCJ=aeLjUtKhDimWat=nPtm3QP+cfA@mail.gmail.com> (raw) In-Reply-To: <CAFEAcA8sE8Rj0GmF71ox4BdDr0UcaS4QwiLUVUUFH5oj+hDhfA@mail.gmail.com> On Tue, May 17, 2022 at 11:54 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Tue, 17 May 2022 at 16:34, Rob Herring <robh@kernel.org> 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. > 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. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Peter Maydell <peter.maydell@linaro.org> Cc: Andre Przywara <andre.przywara@arm.com>, Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Ross Burton <ross.burton@arm.com>, Ard Biesheuvel <ardb@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Russell King <linux@armlinux.org.uk> Subject: Re: [PATCH] of/fdt: Ignore disabled memory nodes Date: Tue, 17 May 2022 12:47:56 -0500 [thread overview] Message-ID: <CAL_JsqLRvEn2E7cpTzQJRCJ=aeLjUtKhDimWat=nPtm3QP+cfA@mail.gmail.com> (raw) In-Reply-To: <CAFEAcA8sE8Rj0GmF71ox4BdDr0UcaS4QwiLUVUUFH5oj+hDhfA@mail.gmail.com> On Tue, May 17, 2022 at 11:54 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Tue, 17 May 2022 at 16:34, Rob Herring <robh@kernel.org> 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. > 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. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-17 17:48 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-17 10:14 [PATCH] of/fdt: Ignore disabled memory nodes Andre Przywara 2022-05-17 10:14 ` Andre Przywara 2022-05-17 15:34 ` Rob Herring 2022-05-17 15:34 ` Rob Herring 2022-05-17 16:54 ` Peter Maydell 2022-05-17 16:54 ` Peter Maydell 2022-05-17 17:47 ` Rob Herring [this message] 2022-05-17 17:47 ` Rob Herring 2022-05-17 19:19 ` Peter Maydell 2022-05-17 19:19 ` Peter Maydell 2022-05-18 16:54 ` Rob Herring 2022-05-18 16:54 ` Rob Herring 2022-05-18 17:54 ` Peter Maydell 2022-05-18 17:54 ` Peter Maydell 2022-05-18 20:46 ` Ard Biesheuvel 2022-05-18 20:46 ` Ard Biesheuvel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAL_JsqLRvEn2E7cpTzQJRCJ=aeLjUtKhDimWat=nPtm3QP+cfA@mail.gmail.com' \ --to=robh@kernel.org \ --cc=andre.przywara@arm.com \ --cc=ardb@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=peter.maydell@linaro.org \ --cc=ross.burton@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.