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: <CAL_JsqLSB=6FduyOE_JNRdy=Uf6dLOcHV-O4qa8psjCobJPaAQ@mail.gmail.com>
Date: Mon, 18 Aug 2025 12:05:07 -0500
From: Rob Herring <robh@...nel.org>
To: Ayush Singh <ayush@...gleboard.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Herve Codina <herve.codina@...tlin.com>, 
	David Gibson <david@...son.dropbear.id.au>, 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 Sun, Aug 17, 2025 at 3:42 AM Ayush Singh <ayush@...gleboard.org> wrote:
>
> On 8/17/25 13:52, Krzysztof Kozlowski wrote:
>
> > On 17/08/2025 10:18, Ayush Singh wrote:
> >>>>> 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.
> >>
> >> Well, I was more worried about matching which phandle belongs to which
> >> symbol easily. Let us assume that 2 symbols will be in each line (after
> >> accounting for the indention and 80 char limit) and we have 70 symbols,
> >> so 35 lines. To check which phandle belongs to the 2nd symbol on line
> >> 25th line of  symbol-names, well, you would at the best case need to
> >> have something like relative line numbers in your editor. Then you know
> >> that the 35th line from the current one is where you need to look.
> >>
> >> In the current syntax, the symbol name and phandle are on the same line.
> >> So well, easy to see which symbols refers to which phandle.
> > OK, that's valid point. Any ideas how to solve it without introducing
> > underscores for properties?
> >
> > Best regards,
> > Krzysztof
>
>
> Well, we can modify `get_phandle_from_symbols_node` to allow matching
> `*_*` to `*-*`. And we can do the same in devicetree easily enough. Not
> sure if implicit loose matching like that are the best idea.
>
> Zephyr does something similar for compatible strings. It pretty much
> replaces the all non alphanumeric characters with `_` in compatible
> string match. Although that is more to do with the limitation they are
> working with, i.e. the devicetree being converted to static headers
> instead of being runtime thing.

This is just going from bad to worse... If there's a real need to use
underscores, then use underscores. But that's all beside the point. I
didn't like v1 and nothing has changed in v2 to change that.

This looks like continuing down the path of working around DTB format
limitations like DT overlays originally did (which both David (IIRC)
and I think was a mistake). But now instead of somewhat hidden,
generated data, you're adding manually written/maintained data. I
don't have any suggestion currently how to avoid that other than we
need to rev the DTB format which no one really wants to hear. Maybe
there's some other solution, but I don't have one ATM.

Rob