linux-kernel - Re: [PATCH v5 3/7] dt-bindings: mikrobus: Add mikrobus-spi binding

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: <CAMuHMdW_u-TxpP49pybyH+FyBN-1R__c=bE=6rnUXFG0RkiYQA@mail.gmail.com>
Date: Fri, 5 Jul 2024 09:44:13 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Conor Dooley <conor@...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>, Michael Walle <mwalle@...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 3/7] dt-bindings: mikrobus: Add mikrobus-spi binding

On Fri, Jun 28, 2024 at 6:48 PM Conor Dooley <conor@...nel.org> wrote:
> On Thu, Jun 27, 2024 at 09:56:13PM +0530, Ayush Singh wrote:
> > Add bindings for MikroBUS boards using SPI interface.
> >
> > Almost all of the properties that are valid for SPI devices can be used
> > except reg. Since the goal is to allow use of the same MikroBUS board
> > across different connectors, config needs to be independent of the actual
> > SPI controller in mikroBUS port(s), it is not possible to define the
> > chipselect by number in advance. Thus, `spi-cs-apply` property is used to
> > specify the chipselect(s) by name.
> >
> > Another important fact is that while there is a CS pin in the mikroBUS
> > connector, some boards (eg SPI Extend Click) use additional pins as
> > chipselect. Thus we need a way to specify the CS pin(s) in terms of
> > mikcrobus-connector which can then handle bindings the actual CS pin(s).
> >
> > Link: https://www.mikroe.com/spi-extend-click SPI Extend Click
> >
> > Signed-off-by: Ayush Singh <ayush@...gleboard.org>

Thanks for your patch!

> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mikrobus/mikrobus-spi.yaml

> > +
> > +required:
> > +  - compatible
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    thermo-click {
> > +      compatible = "maxim,max31855k", "mikrobus,spi";
>
> I am really not keen on what this implies, as I think Rob and I have
> already mentioned, the connector should handle the "mapping" and the
> regular SPI/I2C/whatever bindings for the SPI devices themselves
> should be usable.

Indeed.

The (thermocouple component on the) click itself is not compatible with
"mikrobus,spi", but with "maxim,max31855k". "mikrobus,spi" here means
SPI is used as the transport layer.

I guess you need "mikrobus,spi" because the click is pointed to by the
"board" phandle in the connector, instead of being a subnode of the
connector, like it should be?

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