Message-ID: <20260116100934.7d522b1a@bootlin.com>
Date: Fri, 16 Jan 2026 10:09:34 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
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

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.

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

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.


[1] https://lore.kernel.org/all/20260114171822.2a44d2a5@bootlin.com/

Best regards
Hervé

Powered by blists - more mailing lists