On Wed, 18 May 2022 at 17:54, Rob Herring <robh@xxxxxxxxxx> 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
