Thread (160 messages) 160 messages, 4 authors, 2026-01-29

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

From: David Gibson <hidden>
Date: 2026-01-19 05:18:54
Also in: lkml 

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 [off-list ref] wrote:
quoted
On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
quoted
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.
quoted hunk ↗ jump to hunk
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.
quoted hunk ↗ jump to hunk
	    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?
quoted
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/ (local)

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help