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: <5b2cd46e-8a51-f145-8876-55b12a6d62d1@linux-m68k.org>
Date: Fri, 5 Jul 2024 10:01:11 +0200 (CEST)
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Michael Walle <mwalle@...nel.org>
cc: Andrew Davis <afd@...com>, 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

 	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

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.

[*] 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