Re: [PATCH v3 15/15] Introduce v18 dtb version

[Herve Codina <herve.codina@bootlin.com>]

Hi David,

On Mon, 21 Sep 2026 16:20:02 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Wed, Aug 26, 2026 at 10:31:46AM +0200, Herve Codina wrote:
> > This v18 version will add support for
> >   - Structured tags.
> >     Those tags value definition will allow "old" libfdt, dtc and other
> >     tools to skip unknown tags if encountered in future dtb version.
> > 
> >     libfdt, dtc and other tools implementing version v18 will be able to
> >     skip unknown tags available in dtbd generated with later version of
> >     dtc.
> > 
> >   - dt_flags header field.
> >     For now this flag field is set to 0. It is a placeholder for future
> >     dtb version and could be used to store some dtb related information
> >     such as the kind of dtb. For instance, the future addons format will
> >     use this field to clearly identify that the dtb is an addon dtb.
> > 
> >   - last_comp_version_w header field.
> >     This field is similar to last_comp_version but for writing.
> >     It contains the lowest version of the devicetree data structure with
> >     which the version used can safely perform modifications (taking into
> >     account following rules related to unknown tags).
> >     If this lowest version is greater than the last known supported
> >     version, modification are simply forbidden and lead to a
> >     FDT_ERR_BADVERSION error.
> > 
> > For modification, when an unknown tag that can be skipped is involved
> > and last_comp_version_w allows modifications, the following rules
> > apply:  
> 
> "last_comp_version_w allows modifications" is a bit hard to
> understand.  What exactly is the version number against which we're
> comparing that value?

We had one last_comp_version.

Now we have two last_comp_version, one for reading and one for writing.
We compare again the dtb version supported by our libfdt version.

This comes from the discussion [1]

[1] https://lore.kernel.org/all/CAL_JsqLRrbZje_gGZPBDni6StFa+6rdiECtk49on8VfkP7CDvw@mail.gmail.com/

> 
> >   - When a property is modified, tags related to this property are
> >     removed and the dtb version is downgraded.  
> 
> We need a definition of what "related to" means somewhere.

Yes a tag is said related to a property if it is available after its FDT_PROP and
before the next FDT_PROP (other proterty) of FDT_BEGIN_NODE (subnode) for FDT_NODE_END
(end of node).

This is defined by "structured tag"

Devicetree Specification will be updated to have all of this documentation
available.

> 
> >   - When a property is removed, tags related to this property are
> >     obviously removed. The dtb version is kept unchanged.
> > 
> >   - When a property or a node is added, obviously no unknown tags are
> >     added and the dtb version is kept unchanged.  
> 
> Again, this rule doesn't make sense to me at the same time as the
> property modification rule.

A current libfdt/dtc version cannot add tags which will be defined in the
future.

> 
> >   - When a node is removed, tags related to this node are obviously
> >     removed. The dtb version is kept unchanged.
> > 
> >   - Adding, removing or modifying a property is not considered as a node
> >     modification and so, those operations have no impacts on unknown
> >     tags related to the node. Those node related tags are kept
> >     unchanged.
> > 
> >   - The only modification considered as a node modification is setting
> >     its name. We consider that this operation has no impact on tags
> >     related to the node. Here also, those node related tags and the dtb
> >     version are kept unchanged.
> > 
> >   - Global (dtb related) unknown tags are kept unchanged regardless the
> >     modification done.
> > 
> > In all cases, if unknown tags are not involved in a modification, the
> > dtb version is not downgraded when the modification is made.
> > 
> > It is worth noting that with this v18 version, the dtb version is not
> > downgraded for any modification but only when unknown tags are removed
> > due to a property modification. In v17 or older version any modification
> > led to a dtb version downgrade.  
> 
> I don't think removing that behaviour is safe.  Even if the rules
> above make sense specifically for the metadata tags (which I'm not yet
> convinced of), that's not sufficient.  If nothing else, future
> versions could add extra header fields.  If we modify the tree, those
> header fields could be stale, or even removed.

last_comp_version_w will be used by the future version to prevent this
kind of issue with old version.

Best regards,
Hervé