linux-kernel - Re: [PATCH v5 7/7] dts: ti: k3-am625-beagleplay: Add mikroBUS

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: <ca2d7d4b-c22d-4d14-a216-8c19073e4189@ti.com>
Date: Fri, 5 Jul 2024 11:34:14 -0500
From: Andrew Davis <afd@...com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
        Michael Walle
	<mwalle@...nel.org>
CC: Ayush Singh <ayush@...gleboard.org>, Mark Brown <broonie@...nel.org>,
        Vaishnav M A <vaishnav@...gleboard.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Derek Kiernan <derek.kiernan@....com>,
        Dragan Cvetic <dragan.cvetic@....com>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>,
        Nishanth Menon <nm@...com>, Vignesh Raghavendra
	<vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>, Andrew Lunn
	<andrew@...n.ch>,
        <jkridner@...gleboard.org>, <robertcnelson@...gleboard.org>,
        <linux-spi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 7/7] dts: ti: k3-am625-beagleplay: Add mikroBUS

On 7/5/24 3:01 AM, Geert Uytterhoeven wrote:
>      Hi Michael,
> 
> On Thu, 27 Jun 2024, Michael Walle wrote:
>> On Thu Jun 27, 2024 at 7:07 PM CEST, Andrew Davis wrote:
>>>> +    mikrobus_boards {
>>>> +        thermo_click: thermo-click {
>>>> +            compatible = "maxim,max31855k", "mikrobus-spi";
>>>
>>> I might be missing something, but your solution cannot possibly be
>>> to list every click board that could be connected (all 1500+ of them)
>>> to every mikroBUS connector on every device's DT file..
>>>
>>> Each click board should have a single DTSO overlay file to describe the
>>> click board, one per click board total. And then that overlay should
>>> apply cleanly to any device that has a mikroBUS interface.
>>>
>>> Which means you have not completely solved the fundamental problem of
>>> abstracting the mikroBUS connector in DT. Each of these click device child
>>> nodes has to be under the parent connector node. Which means a phandle
>>> to the parent node, which is not generically named. For instance
>>> if my board has 2 connectors, I would have mikrobus0 and mikrobus1,
>>> the click board's overlay would look like this:
>>>
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> &mikrobus0 {
> 
> Let's use just "&mikrobus" instead...
> 
>>>     status = "okay";
>>>
>>>     mikrobus_board {
>>>         thermo-click {
>>>             compatible = "maxim,max31855k", "mikrobus-spi";
>>>             spi-max-frequency = <1000000>;
>>>             pinctrl-apply = "spi_default";
>>>         };
>>>     };
>>> };
>>
>> If there should only be one DT overlay per click board, how would
>> you apply that to to different connectors?
> 
> You teach fdtoverlay[*] to translate anchors, e.g.
> 
>      fdtoverlay -i base.dtb -o final.dtb \
>             -t mikrobus=mikrobus0 click1.dtbo \
>             -t mikrobus=mikrobus1 click2.dtbo
> 

This basic idea is where I started also, the result is we end
up needing a huge number of "anchor" points. And they would
also be board specific. So we would want to store all these
anchor points in a file, and what better file than another
DT file.

Putting all the translations in a DT file to allow the DT overlay
to become generic is the core idea of this series[0] (looks like
you already found it, linking for other following along).

And as you note, the symbol table trick allows us to do this
without teaching fdtoverlay anything new, so it should work
as-is today for any project already supporting overlays.

> I believe the Raspberry Pi people already have something like that.
> 
> The mikrobus node handles all other translations (e.g. mapping from
> Mikrobus pins to GPIO numbers), so you do not have to handle these
> explicitly when adding an overlay.

This part seems to still be an open item. For pinmux we can name
the pinmux nodes such that their phandles are resolved on overlay
application. For Pin number/name to GPIO number we have "gpio-names",
and the names can also be generic. But for Interrupts and a couple
others, we are still missing a good way to provide a generic mapping
from pin name to number.

Andrew

[0] https://lore.kernel.org/linux-arm-kernel/20240702164403.29067-1-afd@ti.com/

> 
> [*] And anything else that handles overlays (U-Boot, out-of-tree
>      OF_CONFIGFS, ...)
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds