Received-SPF: pass (google.com: domain of linux-kernel+bounces-104924-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 15 Mar 2024 21:00:49 +0000
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Ayush Singh <ayushdevel1325@gmail.com>, linux-kernel@vger.kernel.org,
	jkridner@beagleboard.org, robertcnelson@beagleboard.org,
	Vaishnav M A <vaishnav@beagleboard.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Nishanth Menon <nm@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tero Kristo <kristo@kernel.org>,
	Derek Kiernan <derek.kiernan@amd.com>,
	Dragan Cvetic <dragan.cvetic@amd.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jiri Slaby <jirislaby@kernel.org>,
	Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-spi@vger.kernel.org, linux-serial@vger.kernel.org,
	greybus-dev@lists.linaro.org
Subject: Re: [PATCH v3 1/8] dt-bindings: misc: Add mikrobus-connector
Message-ID: <ZfS3AcIyXd3Lli/w@shell.armlinux.org.uk>
References: <20240315184908.500352-1-ayushdevel1325@gmail.com>
 <20240315184908.500352-2-ayushdevel1325@gmail.com>
 <314a88e0-19cd-4b95-9cf3-aef1c7579eec@linaro.org>
 <ZfSteEmeQX5IUJnU@shell.armlinux.org.uk>
 <5723478b-1717-4f83-959f-14bfce309bcf@linaro.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5723478b-1717-4f83-959f-14bfce309bcf@linaro.org>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>

On Fri, Mar 15, 2024 at 09:40:13PM +0100, Krzysztof Kozlowski wrote:
> On 15/03/2024 21:20, Russell King (Oracle) wrote:
> > On Fri, Mar 15, 2024 at 09:09:11PM +0100, Krzysztof Kozlowski wrote:
> >>> +properties:
> >>> +  compatible:
> >>> +    const: mikrobus-connector
> >>
> >> Hm, why do you create binding for the connector, not for some sort of
> >> controller? Please provide some rationale for this in commit msg.
> > 
> > I think you have a distorted view. I refer you to the Mikroe mikroBUS
> > specification - it's _just_ a connector which provides a fairly
> > standardised purpose for each pin and the electrical specifications.
> > For example of the pins: power, UART, SPIs, I2C, PWM, and analogue
> > pins.
> 
> I refer to the commit msg or description in the binding and there is
> nothing explained like this. Yeah, true, I could google every possible
> bus specification, but I also expect some sort of help here by the patch
> submitter.
> 
> The binding looks like binding for a connector, not for some sort of
> controller, then are you saying the control part it is purely in
> software? That's how DTS looks like, but then my question is are there
> some sort of controller which would also perform this?

There is, as far as I'm aware, no "controller" for a mikroBUS. As I
tried to explain, it's a bunch of pins with defined standard functions.
The idea seems to be they're connected to a SoC with a pinmux that can
reconfigure the function of the pin.

At least that's how the hardware implementations I've seen do it.

> > This isn't a choice at all. Here's the list of pins:
> > 
> > Analog - AN
> > Reset - RST
> > SPI Chip Select - CS
> > SPI Clock - SCK
> > SPI Master Input Slave Output - MISO
> > SPI Master Output Slave Input - MOSI
> > VCC-3.3V power - +3.3V
> > Reference Ground - GND
> > PWM - PWM output
> > INT - Hardware Interrupt
> > RX - UART Receive
> > TX - UART Transmit
> > SCL - I2C Clock
> > SDA - I2C Data
> > +5V - VCC-5V power
> > GND - Reference Ground
> > 
> > Any data pin can be a GPIO if e.g. a relay board is plugged in, even
> > if some of the other pins are used for e.g. UART purposes. For example,
> > a GPS board that provides the GPS data over the UART pins, and the
> > PPS signal through a different pin.
> 
> And could you not have some certain features supported? Could have some
> pins just pull down / not connected?

A board plugged in doesn't have to use all the functions. I gave two
examples. Apart from the power pins,

The GPS board as I stated uses the two UART pins, and some GPS boards
route the PPS signal to another pin on the connector, but that's
entirely optional. Another pin might be used as a GPIO as an enable.

In the case of a relay board I've had, the SPI CS pin is used for one
relay, and the PWM pin for the other relay.

I also have a BME280 humidity/pressure sensor board, which just uses
the two I2C pins.

What is supported by a board is down to the board. Which pins it
connects to is down to the board. Which board is plugged in is up
to the user.

That is essentially the long and short of mikroBUS - I hope I've
given a good overview of it.

I am slightly confused by this series, because it seems the Linux
"mikroBUS" layer requires a one-wire EEPROM on the boards, but the
official mikroBUS specification doesn't state this. The author
really needs to clarify what they are implementing here. Are they
truly implementing mikroBUS as defined by Mikroe, or are they
implementing someone's custom extension to it that adds an
identification EEPROM - in which case I would argue that this
code as it stands is not suitable for mainline as long as it
purports to be implementing support for Mikroe's mikroBUS.

Hence, I think we should back off on reviewing this until we have
that clarification.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!