linux-kernel - Re: [RFC PATCH 06/77] Add support for FDT_REF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLx-NWM=gFdQfQ1Nw10ii2n5gX93WgH+zTcbHRt=Ze_vA@mail.gmail.com>
Date: Thu, 15 Jan 2026 09:54:22 -0600
From: Rob Herring <robh@...nel.org>
To: David Gibson <david@...son.dropbear.id.au>
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 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.

>  * 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). 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. 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).

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.

Rob