Message-ID: <aW3MJTC97VSwGsMm@zatzit>
Date: Mon, 19 Jan 2026 17:16:05 +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 Thu, Jan 15, 2026 at 09:54:22AM -0600, Rob Herring wrote:
> On Wed, Jan 14, 2026 at 6:51 PM David Gibson
> <david@...son.dropbear.id.au> 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@...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
> 
> 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.

I mostly agree.  But as noted, we can't advertise v18 (or whatever)
support until we actually *do* support it - which would imply having
some docs / specs on what exactly is in v18.  So the series will need
some re-ordering to allow pieces to be merged earlier.

> >  * phandles aren't just another type, they have structural relevance
> >    which makes them a special case
> 
> Fair enough.
> 
> What's similar is we need to define FOO is at offset X just like the
> markers within dtc. We can add other types later, I'm just asking that
> the design here for new tags and phandles accounts for that.
> 
> > 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.
> 
> json has no concept of integer sizes (and numbers are floats).

Good point, and dtb has heavier than many need of true 64-bit ints.
It's a real half-ton of flies in a mostly pretty decent data model :(.

> The
> typical work-around for that is encode everything as a string and then
> we're pretty much back to everything's a byte array. Pretty sure we've
> been thru this already. So I don't know what format we'd use. I've not
> come across one.

ASN.1? CBOR? Messagepack? Protobuf?  I don't love any of those, but
I'm not sure they'd be *more* clunky than something we cobble together
on top of dtb.

> Perhaps just DTS as that does have the type
> information. :) In any case, I'm not interested in a revolution, just
> evolution. I want a format that transparently works with only an
> updated libfdt. Anything else is simply going to go nowhere (as
> evident by the last 15 years of new DTB format discussions).

As a rule, I also prefer evolution to revolution.  But there can come
a point where you're straining the thing you're building on further
than makes sense any more.

> I know you aren't a fan of relying on .dts information for type
> information, but that's not the only source anymore. We now have an
> entire database of every last property and its type. That could be
> what's used to populate type information. Again, we don't have to
> define how we do it now, just allow for it (and any other metadata we
> have yet to think about) in the DTB format changes.

I guess it depends a bit how you're thinking of this type information.
Are you thinking of it as an intrinsic part of the dtb information
that a consumer (like the kernel) would use?  Something akin to the
symbols or relocation information in an ELF object.

Or are you thinking of it as something for the benefit of intermediate
tools, that could be stripped out before going to the final consumer?
Something like debug symbols in an ELF object.

I'm open to the second approach, although I'm still a bit concerned
that once it's there as "debug" information things might start relying
on it which shouldn't.

-- 
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