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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <412231e0-5fcf-4708-aeab-cc3aa38c817e@kernel.org>
Date: Wed, 28 May 2025 10:06:34 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ayush Singh <ayush@...gleboard.org>,
 Herve Codina <herve.codina@...tlin.com>,
 David Gibson <david@...son.dropbear.id.au>, Andrew Davis <afd@...com>,
 Geert Uytterhoeven <geert@...ux-m68k.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Saravana Kannan <saravanak@...gle.com>
Cc: devicetree@...r.kernel.org, devicetree-compiler@...r.kernel.org,
 linux-kernel@...r.kernel.org, Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 1/7] dt-bindings: Add support for export-symbols node

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