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

Herve Codina <[email protected]>
Newsgroups org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Organization Bootlin
Message-ID <[email protected]>
Hi Krzysztof,

On Wed, 4 Jun 2025 20:35:51 +0200
Krzysztof Kozlowski <[email protected]> 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é
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.