Re: [RFC PATCH 06/77] Add support for FDT_REF_LOCAL dtb tag
From: Herve Codina <herve.codina@bootlin.com>
Date: 2026-01-16 10:17:09
Also in:
lkml
On Fri, 16 Jan 2026 11:16:16 +0100 Herve Codina [off-list ref] wrote:
Hi Rob, David, On Thu, 15 Jan 2026 09:54:22 -0600 Rob Herring [off-list ref] wrote:quoted
On Wed, Jan 14, 2026 at 6:51 PM David Gibson [off-list ref] wrote:quoted
On Tue, Jan 13, 2026 at 01:22:08PM -0600, Rob Herring wrote:quoted
On Mon, Jan 12, 2026 at 8:20 AM Herve Codina [off-list ref] wrote:quoted
FDT_REF_LOCAL dtb tag is a meta-data tag attached to a property. It indicates that the property defined before this tag (FDT_PROP) uses a phandle value and the node related to this phandle value is local (i.e. the node is present in the device-tree blob). It is followed by one value: - offset (32bit): Offset in the property data where the phandle is available. Example: FDT_PROP 0x00000008 xxxxxxxx 0xca 0xfe 0xde 0xca 0x01 0x02 0x03 0x04 FDT_REF_LOCAL 0x00000004 This means that at the offset 4 of the property data, the value (0x01020304) is a phandle and the related node is available in the dtb. This is what is encoded in the dtb when the related dts has a property with the value set to <0xcafedeca &foo> with 'foo' a reference to an existing node where the phandle value is 0x01020304. If several local phandles are used in the property data, several FDT_REF_LOCAL are present after the FDT_PROP tag. Each of them points with its offset value to the position of one phandle. For instance, if a first property with 8 bytes of data has a phandle value at offset 4 and a second property with 16 bytes of data has phandle values at offset 0 and 8, the following tags sequence is present: FDT_PROP 0x00000008 xxxxxxxx <data bytes> FDT_REF_LOCAL 0x00000004 FDT_PROP 0x00000010 xxxxxxxx <data bytes> FDT_REF_LOCAL 0x00000000 FDT_REF_LOCAL 0x00000008To follow up on my desire to both be easily extended and have more type info, I have something like this in mind: FDT_TYPE_INFO 0x10 FDT_REF_LOCAL 0x0 FDT_TYPE_U32 0x4 FDT_REF_LOCAL 0x8 FDT_TYPE_U32 0xcI think general type info should be out of scope for this: * This series is already enormous and complicated without thatIt is enormous, but I don't think the intention was to finalize and merge it all at once. I certainly don't intend to review it all now. The final result looks sane to me and with that we have a good idea what information needs to go in the DTB. I think the first step is to define the new metadata tags and what DTB format changes are needed.Indeed, the goal of this RFC is to give the big picture and open discussions. FDT_TYPE_INFO tag is a container. It just groups other tags together. I don't use the term TYPE in the proposal related to generic tag values [1]. I use FDT_INFO_PROPERTY which is more generic. Best regards, Hervé
[1] https://lore.kernel.org/all/20260114171822.2a44d2a5@bootlin.com/ (local) -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com