linux-kernel - Re: [RFC PATCH 02/77] Introduce v18 dtb version

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_JsqLdKMPYq0q1Tw+8Ts9uD=AZR2HGDF2W9iY6Y=EGg=ujTw@mail.gmail.com>
Date: Tue, 20 Jan 2026 14:38:45 -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 02/77] Introduce v18 dtb version

On Sun, Jan 18, 2026 at 11:18 PM David Gibson
<david@...son.dropbear.id.au> wrote:
>
> On Fri, Jan 16, 2026 at 10:09:34AM +0100, Herve Codina wrote:
> > Hi David,
> >
> > On Thu, 15 Jan 2026 11:12:49 +1100
> > David Gibson <david@...son.dropbear.id.au> wrote:
> >
> > > On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > > > This v18 version will add support for
> > > >  - metadata in device-tree blobs in order to have a better handling of
> > > >    phandles and unresolved references.
> > > >  - Addon device-tree blob (successor of device-tree overlay)
> > > >  - Import and export symbols feature
> > > >  - multiple trees in a addon device-tree blob (i.e. root device tree and
> > > >    orphan node tree)
> > >
> > > So, once this patch is applied, the rest of the series pretty much has
> > > to be applied "atomically" - otherwise a version built in the interim
> > > will be lying in saying that it supports v18.
> > >
> > > I therefore suggest moving any changes that *can* be moved before this
> > > patch, should be moved before this patch.  That will assist in
> > > reviewing and merging the series piecemeal, rather than as a single
> > > giant blob.
> > >
> > >
> > > Regarding the content itself.  It seems like this is a pretty major
> > > change to the dtb format - maybe that would suggest bumping the
> > > version by more than one (e.g. like we went from v3 to v16 in the
> > > past).
> >
> > I see your point.
> >
> > Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
> > related to the generic tag value definition to support those 'unknown tag'
> > could help here.
>
> Having a standard encoding of tag length so unknown tags can be
> skipped is a reasonable idea.  I think you do need provision to mark a
> tag as "safe to ignore" or not - e.g. something like FDT_BEGIN_NODE
> could never be safely ignored.
>
> > As a reminder here, this generic tag value definition consist in:
> > --- 8< ---
> > A tag value is on 32bits. We can define the structure of this value.
> >   - bit 31 (msb):
> >      - 0: This is not a new kind to tag and so it doesn't follow this definition.
> >           All existing tags are in this category
> >      - 1: New kind of tag adopting this definition
> >
> >   - bits 30..28:
> >      tag data length encoding
> >      0b000: No data related to the tag
> >      0b001: 1 data cell (u32) directly follows the tag
> >      0b010: 2 data cells (2 u32) directly follow the tag
> >      ...
> >      0b110: 6 data cells (6 u32) directly follow the tag
> >      0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
> >             of data available just after this cell (including any padding
> >             if needed).
>
> I'd suggesting giving a byte length not including alignment padding.
> That way if you wanted to encode a bytestring in there, you wouldn't
> need a way of encoding the unpadded length in adddition to the
> standard way encoding the padded length.
>
> >           Because this size include some possible padding, its value is a
> >             multiple of 4 bytes.
> >             The offset of the tag + 4 + size points to the next tag.
> >
> >
> >   - bit 27..0
> >      tag specific identifier
> > --- 8< ---
> >
> > I mean dtb version v20 could be:
> >
> >  - New header size with dt_flags added in the header (if this new field is
> >    kept).
> >
> >  - Support for the generic tag values and so the notion of 'unknown tag'
> >
> > With that done, everything else added afterward will have no impact on the
> > dtb format itself.
>
> Well... maybe.  It's not entirely clear to me whether all the new tags
> can be safely ignored by something that doesn't understand them.
> e.g. a consumer can't safely ignore the tags which give unresolved
> phandle references if it then expects the phandle values in the actual
> property values to be correct.

I think we'd want some higher level "this is an addon or base DT" than
presence of tags. Maybe that's just the version. Perhaps a new header
field to say this is a base or addon DT. Or both?

Everything in this series intended for the base DT should be safe to
ignore just as __symbols__ (and __local_fixups__ if you add /plugin/)
is safe to ignore. It's only software that understands and wants to
use the new "addons" that needs to understand.

Rob