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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 28/05/2025 09:59, Ayush Singh wrote:
> On 5/28/25 00:01, Krzysztof Kozlowski wrote:
> 
>> On 30/04/2025 14:51, Herve Codina wrote:
>>> An export-symbols node allows to export symbols for symbols resolution
>>> performed when applying a device tree overlay.
>>>
>>> When a device tree overlay is applied on a node having an export-symbols
>>> node, symbols listed in the export-symbols node are used to resolve
>>> undefined symbols referenced from the overlay.
>>
>> I have impression that this is being discussed in three places
>> simultaneously - here, DT spec and DT schema. I don't know how to solve
>> the multiplication, but I will keep answering here, because that's my part.
>>
>>> This allows:
>>>    - Referencing symbols from an device tree overlay without the need to
>>>      know the full base board. Only the connector definition is needed.
>>>
>>>    - Using the exact same overlay on several connectors available on a given
>>>      board.
>>>
>>> For instance, the following description is supported with the
>>> export-symbols node:
>>>   - Base device tree board A:
>>>      ...
>>>      foo_connector: connector1 {
>>>          export-symbols {
>>>             connector = <&foo_connector>;
>>>          };
>>>      };
>>>
>>>      bar_connector: connector2 {
>>>          export-symbols {
>>>             connector = <&bar_connector>;
>>>          };
>>>      };
>>>      ...
>> And what would this mean? Which symbol is exported - foo or bar?
>>
>>>   - Base device tree board B:
>>>      ...
>>>      front_connector: addon-connector {
>>>          export-symbols {
>>>             connector = <&front_connector>;
>>>          };
>>>      };
>> <from my other reply in private>
>> Another problem is that the board DTS should not care about overlays. It
>> feels like breaking encapsulation and I cannot imagine now adding 1000
>> export-symbols, because every i2c, spi, mikrobus or PCI slot could have
>> an overlay applied.
>>
>> You could argue that only few nodes will be exported like this, so only
>> real mikrobus connectors. Then I will argue: look at aliases. People
>> alias everything everywhere, not following the guidelines.
>>
>> If we assume that such overlays are designed for specific boards, thus
>> there will be only one or two exported symbols not 1000, then what is
>> the benefit of export symbols comparing to referencing by full path?
>> </end from my other reply>
> 
> Can you explain how referencing by full path will work in connector + 
> addon board setups?
> 
> The full path will be dependent on the connector, which means the same 
> addon  board overlay cannot work for different connectors.

That was the assumption.

> 
> 
>>
>> And with above assumption - such overlays designed per board - plus my
>> first point about duplicated exports:
>> connector = <&foo_connector>;
>> connector = <&bar_connector>;
>>
>> why not exporting the symbol with the same name? E.g.:
>>
>>       foo_connector: connector1 {
>>           export-symbols {
>>              whatever-property-style = <&foo_connector>;
>>           };
>>       };
>>
>> and overlay:
>>
>>       node {
>>           ...
>>           connector = <&foo_connector>;
>>           ...
>>       };
> 
> 
> Isn't this overlay tied to `foo_connector`, i.e. it cannot be used with 
> `bar_connector`?

I don't know what the example tried to say. I asked the question, so
don't ask question to my question. We both apparently do not know. What
is the meaning of that example I questioned? To which connector this is
an overlay? Which symbol is exported for that example?

Best regards,
Krzysztof