Re: [RFC PATCH 06/77] Add support for FDT_REF_LOCAL dtb tag

Hi Rob, David,

On Thu, 15 Jan 2026 09:54:22 -0600
Rob Herring <[email protected]> wrote:

> On Wed, Jan 14, 2026 at 6:51 PM David Gibson
> <[email protected]> wrote:
> >
> > On Tue, Jan 13, 2026 at 01:22:08PM -0600, Rob Herring wrote:  
> > > On Mon, Jan 12, 2026 at 8:20 AM Herve Codina <[email protected]> wrote:  
> > > >
> > > > 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 0x00000008  
> > >
> > > To 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 0xc  
> >
> > I think general type info should be out of scope for this:
> >  * This series is already enormous and complicated without that  
> 
> It 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é