linux-kernel - Re: [PATCH v2 1/7] dt-bindings: Add support for export-symbols node

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aL5fEzN2S058oSAI@zatzit>
Date: Mon, 8 Sep 2025 14:44:03 +1000
From: David Gibson <david@...son.dropbear.id.au>
To: Ayush Singh <ayush@...gleboard.org>
Cc: Herve Codina <herve.codina@...tlin.com>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Rob Herring <robh@...nel.org>, Andrew Davis <afd@...com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org,
	devicetree-compiler@...r.kernel.org, linux-kernel@...r.kernel.org,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 1/7] dt-bindings: Add support for export-symbols node

On Wed, Jun 18, 2025 at 03:24:07PM +0530, Ayush Singh wrote:
> 
> On 6/18/25 15:02, Herve Codina wrote:
> > Hi Krzysztof,
> > 
> > On Wed, 4 Jun 2025 20:35:51 +0200
> > Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > 
> > ...
> > 
> > > > Symbols are exported only when an overlay is applied on the node where the
> > > > export-symbols node is available. Those symbols are visible only from the
> > > > overlay applied. Symbols exported thanks to export-symbols are not global
> > > > to the all device-tree (it is not __symbols__) but local to a node.
> > > > 
> > > > If an overlay is applied at connector1 node, it can use the 'connector'
> > > > symbols and thanks to export-symbols, the 'connector' symbol will be
> > > > resolved to foo_connector.
> > > > 
> > > > If the overlay is applied at connector2 node, the 'connector' symbol is then
> > > > resolved to bar_connector.
> > > OK, this explains a lot. Unless I missed it, would be nice to include it
> > > in binding description.
> > Sure, I will add something in the next iteration.
> > 
> > ...
> > 
> > > > > > +patternProperties:
> > > > > > +  "^[a-zA-Z_]?[a-zA-Z0-9_]*$":
> > > > > This messes up with coding style which I would prefer keep intact.
> > > > > Basically these properties will be using label style.
> > > > Yes, those properties remap phandles.
> > > > 
> > > > Their names are the name of the label used from the overlay and their
> > > > values are the phandle mapped.
> > > > 
> > > > You already have this kind properties using label style in __symbols__,
> > > > __fixups__, __local_fixups__ nodes.
> > > I have them in DTB, but I don't have these in DTS. The exported-symbols
> > > would be in the DTS and that is what coding style is about.
> > > 
> > I think export-symbols has to be in DTS.
> > Maybe it could be described in an other way in order to avoid the coding style
> > issue you reported.
> > 
> > Hardware:
> >    i2c0 from SoC --------- connector 1, I2C A signals
> >    i2c1 from SoC --------- connector 1, I2C B signals
> > 
> >    connector1 {
> >        export-symbols {
> > 	  i2c_a = <&i2c0>;
> > 	  i2c_b = <&i2c1>;
> >        };
> >    };
> > 
> > In order to avoid the coding style issue, this could be replace
> > with:
> >   connector1 {
> >        export-symbols {
> > 	  symbol-names = "i2c_a", "i2c_b";
> > 	  symbols = <&i2c0>, <&i2c1>;
> >        };
> >    };
> > 
> > Krzysztof, Rob, do you think this could be accepted ?
> > 
> > Ayush, David, do you thing this could be easily implemented in fdtoverlay ?
> > 
> > Best regards,
> > Hervé
> > 
> 
> Well, it is possible.
> 
> However, on connectors like pb2 header, there will be 50-100 export symbols.
> So it will start becoming difficult to maintain.
> 
> Additionally, the further away we move from __symbols__ style, the more
> difficult the implementation will become since we can currently very easily
> piggy-back on __symbols__ resolution implementation.

I think that should be a non-goal.  Current __symbols__ resolution was
a quick hack.  Design what makes sense rather than being tied to the
ugly past.

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