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

David Gibson <[email protected]> Thu, 15 Jan 2026 11:34:44 +1100
Newsgroups	org.kernel.vger.devicetree-spec,org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID	<aWg2JJstA0F-h9hi@zatzit>
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
 * phandles aren't just another type, they have structural relevance
   which makes them a special case

Plus, I'm actually pretty dubious about adding type information to
dtbs in the first place.  It gives the impression that dt property
values are self-describing, but they're not.  If you want a
self-describing format, I think you'd be better off dropping the
OF-related past entirely, and using json or one of the various other
modern self-describing structure data formats.

> Length is 16 because I would do u16 for the types and lengths. I'm not
> sure what the max property length is. In theory 2^32, but I suspect
> we'd run into other issues (e.g. libfdt offsets are 32-bit on 32-bit
> systems). We could also do 8 bits for type and 24 bits for offset.
> Offset could also be relative to the prior offset.

Structurally dtbs are limited to 2^32 bytes, by policy they're limited
to 2^31 bytes (so we can safely store an offset in a signed 32-bit
int).

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson
signature.asc (application/pgp-signature, 833 B)