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: <CAMuHMdXvxXZUE0LwCYPt3HyuQTvM6Rus_RidJ24Ttd_4e_m-HQ@mail.gmail.com>
Date: Fri, 5 Jul 2024 10:19:50 +0200
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

On Fri, Jul 5, 2024 at 10:01 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> 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";

Max31855k is an SPI device, so its device node should be under an "spi"
subnode (with proper #{address,size}-cells) of the mikrobus connector,
and use a suitable unit-address and "reg" property, pointing to the
right SPI chip select.

> >>                      spi-max-frequency = <1000000>;

This belongs to the "spi" subnode, not the Max31855k device node.

> >>                      pinctrl-apply = "spi_default";

This belongs to the mikrobus connector node.

> >>              };
> >>      };
> >> };

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