Message-ID: <aW29fwFEB6_qjVEc@zatzit>
Date: Mon, 19 Jan 2026 16:13:35 +1100
From: David Gibson <david@...son.dropbear.id.au>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Rob Herring <robh@...nel.org>, 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 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.
> 
> Only libfdt and dtc will have versions defined at some point with support for
> some new flags or new keyword.
> 
> What do you think about this v20 dtb version?
> 
> > 
> > It would also be nice to have some docs for the new dtb extensions
> > before or at the same time as this.
> 
> Yes, the generic tag value definition.

We'd want that, but it's not enough.  The specific tag types should be
documented as well.

> 
> 
> [1] https://lore.kernel.org/all/20260114171822.2a44d2a5@bootlin.com/
> 
> Best regards
> Hervé
> 

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