Re: [PATCH v2 1/7] dt-bindings: Add support for export-symbols node
Krzysztof Kozlowski <[email protected]>
| Newsgroups | org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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