Re: [RFC PATCH 64/77] dtc: Add support for references by path involving orphan nodes

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]

On Wed, Jan 21, 2026 at 05:30:12PM +0100, Herve Codina wrote:
> Hi David,
> 
> On Wed, 21 Jan 2026 20:06:11 +1100
> David Gibson <david@gibson.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@gibson.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.

Either I'm missing something, or I'm not explaining what I have in
mind well.  My itention here is to *reduce* the number of tags.

The proposal has two ways of adjusting a property referring to a
phandle: a) if the referenced node is within this tree fragment
(local), b) if the referenced node is external.

Clearly we need (b), but I'm wondering if there's any way we can
remove (a), using the method for (b) instead.  i.e. do local
references via label, just like external references.

Here's one possible idea: I've said elsewhere that I'm not convinced
the current proposal adequately handles the case of an addon that
requires several upstream connectors.  The obvious way of addressing
that would mean that imported / referenced symbols aren't global to
the whole addon, but instead are specific to a specified upstream
connector.  So, say each phandle fixup tag contained both a namespace
and a label.  The namespace selects which upstream connector we're
referrring to, the label says what symbol within that connector we're
referring to.

If we went with a scheme like that, we could reserve a special
namespace id to mean "this addon itself".  So, we can use the same
sort of fixup tag for both local and external references, at the cost
of having to explicitly "export" symbols/labels for the locally
referenced nodes.  So, something like

Base tree:
	...
	foo0: foobus@12345 {
		/export/ bridge = &foo0;
	   	/export/ intc = &/path/to/board/intc;
		compatible = "foobus";
		...
	};
	bar0: barbus@abcde {
		/export/ gpio = &/path/to/gpio/mux;
		compatible = "barbus";
		...
	};

Addon:
	/* Declare our upstream connectors */
	/requires/ foo "foobus";
	/requires/ bar "barbus";
	
	&foo.bridge {
		local_intc: local-intc@XXX {
			interrupt-parent = <&foo.intc>;
			...
		};
		widget@YYY {
			compatible = "widget31415", "widget3000";
			interrupt-parent = <&LOCAL.local_intc>;
			interrupts = <...>;
			gpio = <&bar.gpio>;
		}
	}

By the time we compile to dtb, those namespace IDs could likely be
ints, rather than strings.

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

Does it, though?  We already need the import/export mechanism, so what
prevents us from using it locally?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]