Re: [PATCH v2 1/7] dt-bindings: Add support for export-symbols node
Ayush Singh <[email protected]>
| Newsgroups | org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 6/18/25 15:02, Herve Codina wrote: > 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é > 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