Message-ID: <20260121173012.2a087367@bootlin.com>
Date: Wed, 21 Jan 2026 17:30:12 +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 64/77] dtc: Add support for references by path
 involving orphan nodes

Hi David,

On Wed, 21 Jan 2026 20:06:11 +1100
David Gibson <david@...son.dropbear.id.au> wrote:

> On Mon, Jan 19, 2026 at 05:38:31PM +0100, Herve Codina wrote:
> > On Thu, 15 Jan 2026 18:01:39 +1100
> > David Gibson <david@...son.dropbear.id.au> wrote:
> >   
> > > On Mon, Jan 12, 2026 at 03:19:54PM +0100, Herve Codina wrote:  
> > > > Referencing a sub-node from an orphan node using a path is needed.
> > > > 
> > > > Indeed, using the following snippet:
> > > > --- 8< ---
> > > > /addon/;
> > > > 
> > > > &node1 {
> > > > 	subnode {
> > > > 		foo-phandle = <&foo_label>;
> > > > 	};
> > > > };
> > > > 
> > > > &node2 {
> > > > 	foo_label: foo {
> > > > 		prop = <1>;
> > > > 	};
> > > > };
> > > > --- 8< ---
> > > > 
> > > > Even if node2 is an orphan node, foo is a local node. foo-phandle
> > > > references the foo node using a label.    
> > > 
> > > Another option would be to eliminate the idea of local references, and
> > > require a symbol be attached to things that you want to reference by
> > > label.  
> > 
> > Hum, new kind of references.  
> 
> No, I'm trying to remove a type of reference: I'm suggesting using the
> same format as for external references on local references as well.
> That might mean things referenced need to be both exported and
> imported by the tree creating them.  That might be worth it to reduce
> the number of cases.

Hum, this means a new tags.

local references: ok, phandle to to local node.

external references: phandle to external node.
This has to be resolved based on exports available in the device-tree the
addon is applied to.

Here, the node is not external. It is available in the addon and so it is
a local node.

No import/export mechanism is needed to resolve the phandle. Indeed, this
phandle is already well defined (resolved) in the addon blob.

Having a kind of 'local' import/export to allow local cross-tree references
is going to add an extra complexity where it is not needed.

Look at the related test (patch 65).

In the tests/metadata_addon_references.dts, you can find:
--- 8< ---
&base1 {
	b1_addon: addon-node {
		prop = <2>;
	};
};

&base2 {
	addon-node1 {
		ref-base1-addon-node = <&b1_addon>;
	};
	...
};
--- 8< ---

Converted to dtb and analyzed by fdtdump, this leads to
(tests/metadata_addon_references.dtb.expect):
--- 8< ---
&base1 {
    addon-node {
        prop = <0x00000002>;
        phandle = <0x00000001>;
    };
};
&base2 {
    addon-node1 {
        ref-base1-addon-node = <0x00000001>;
        // [FDT_REF_LOCAL] ref-base1-addon-node[0]
    };
    ...
};
--- 8< ---

This dtb, as all dtbs, can be converted back to a dts.

Having a syntax to reference orphan node by path allows to use this
syntax in the 'ref-base1-addon-node' property. You can find it in
tests/metadata_addon_references.dtb.dts.expect
--- 8< ---
&base1 {

	addon-node {
		prop = <0x02>;
		phandle = <0x01>;
	};
};

&base2 {

	addon-node1 {
		ref-base1-addon-node = <&{$base1/addon-node}>;
	};
	...
};
--- 8< ---

We could only use the phandle value:
   ref-base1-addon-node = <0x01>;

Which is perfectly legit and fully matches what is encoded in the dtb.

But I think it was very interesting, thanks to meta-data, to identify that
this is a phandle and so use a reference instead of a integer (phandle).

No label are stored in the dtb and there is no need to store them. Further
more, a node, in a dts can have several label. Which one to store? The
first one, all, ...

Using export, lead to the node visible to any addon applied. That's not the
expectation.

Using import, means the symbol is external. That's not the case.

A local node exists in the dtb. We should be able to reference it by path.

/ {
    foo {
	bar {
	    ...
	};
    }
};

With the root tree, the 'bar' node, can be referenced by /foo/bar.

Now, with orphan:
&orphan {
    foo {
        bar {
	    ....
        };
    };
};

How to reference 'bar' by path?

We need to identify 'orphan' instead of root ('/') $orphan/foo/bar is the
syntax I propose to do that. Of course, this syntax can be discussed.

IMHO, I thing the feature consisting in referencing by path a node in an
orphan tree is needed and avoid extra complexity.

Best regards,
Hervé

> 
> > We have reference by phandle to local nodes. Reference by symbol for
> > external nodes (i.e. nodes not present in current dtb).
> > 
> > Now new kind of reference for node available in the current dtb but
> > in a different tree (orphan tree).
> > 
> > For that we need to:
> >   - Mark the phandle value in the property as a cross-tree phandle
> >     reference
> >   - Add the symbol label in the referenced node.
> > 
> > When the addon is applied, this new kind of reference need to be taken
> > into account in a new way:
> >   - The phandle value in the referenced node need to be updated in the
> >     same way as all other phandle value in nodes to avoid collisions.
> >   - The cross-tree reference needs to be resolved.
> > 
> > This adds an unneeded complexity.
> > 
> > IMHO, we shouldn't eliminate local references.
> > 
> > We need to reference all possible local nodes by path even if cross-tree
> > due to orphan tree is involved.
> > 

Powered by blists - more mailing lists