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

[Herve Codina]

On Fri, 16 Jan 2026 11:16:16 +0100
Herve Codina <herve.codina@xxxxxxxxxxx> wrote:

> Hi Rob, David,
> 
> On Thu, 15 Jan 2026 09:54:22 -0600
> Rob Herring <robh@xxxxxxxxxx> wrote:
> 
> > On Wed, Jan 14, 2026 at 6:51 PM David Gibson
> > <david@xxxxxxxxxxxxxxxxxxxxx> 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 <herve.codina@xxxxxxxxxxx> 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é

[1] https://lore.kernel.org/all/20260114171822.2a44d2a5@xxxxxxxxxxx/

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com