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: <3ff4b3f9-cc8d-4044-b2eb-33010d8951c0@kernel.org>
Date: Sun, 17 Aug 2025 09:41:24 +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>, Rob Herring <robh@...nel.org>
Cc: Andrew Davis <afd@...com>, Geert Uytterhoeven <geert@...ux-m68k.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>, 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 18/06/2025 11:54, Ayush Singh wrote:
> 
> On 6/18/25 15:02, Herve Codina wrote:
>> Hi Krzysztof,
>>
>> On Wed, 4 Jun 2025 20:35:51 +0200
>> Krzysztof Kozlowski <krzk@...nel.org> 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.


And the first syntax solves this how? I don't see the practical difference.

> 
> 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.


I care more how I read DTS, so complexity in dtc is less important to me
than consistent DTS style.

Best regards,
Krzysztof