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, David, Rob,

Any opinion?

Best regards,
Hervé

On Wed, 18 Jun 2025 15:24:07 +0530
Ayush Singh <[email protected]> wrote:

> On 6/18/25 15:02, Herve Codina wrote:
...

> >  
> >>>>> +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.
> 
> 
> Best Regards,
> 
> Ayush Singh
>
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.