Message-ID: <aWg2JJstA0F-h9hi@zatzit>
Date: Thu, 15 Jan 2026 11:34:44 +1100
From: David Gibson <david@...son.dropbear.id.au>
To: Rob Herring <robh@...nel.org>
Cc: Herve Codina <herve.codina@...tlin.com>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ayush Singh <ayush@...gleboard.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	devicetree-compiler@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree-spec@...r.kernel.org,
	Hui Pu <hui.pu@...ealthcare.com>,
	Ian Ray <ian.ray@...ealthcare.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH 06/77] Add support for FDT_REF_LOCAL dtb tag

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@...tlin.com> 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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists