lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXq_On_DobrGt2fO@zatzit>
Date: Thu, 29 Jan 2026 13:00:26 +1100
From: David Gibson <david@...son.dropbear.id.au>
To: Herve Codina <herve.codina@...tlin.com>
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

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

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@...45 {
		/export/ bridge = &foo0;
	   	/export/ intc = &/path/to/board/intc;
		compatible = "foobus";
		...
	};
	bar0: barbus@...de {
		/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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ