linux-kernel - Re: [PATCH v5 1/7] dt-bindings: connector: Add mikrobus-connector

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]

Date: Fri, 28 Jun 2024 11:00:28 -0600
From: Rob Herring <robh@...nel.org>
To: Ayush Singh <ayush@...gleboard.org>
Cc: Michael Walle <mwalle@...nel.org>, Mark Brown <broonie@...nel.org>,
	Vaishnav M A <vaishnav@...gleboard.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 1/7] dt-bindings: connector: Add mikrobus-connector

On Thu, Jun 27, 2024 at 10:59:46PM +0530, Ayush Singh wrote:
> On 6/27/24 22:42, Michael Walle wrote:
> 
> > Hi,
> > 
> > Could you give us a DT snippet of how this should look like with a
> > board?
> > 
> > On Thu Jun 27, 2024 at 6:26 PM CEST, Ayush Singh wrote:
> > > +  board:
> > > +    description: board attached to mikrobus connector
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > Shouldn't this be a subnode of the connector?
> > 
> > i.e.
> > 
> > connector {
> > 	compatible = "mikrobus-connector";
> > 
> > 	// phandles to the parent controllers

These are per bus, so put them in the child bus nodes:

> > 
> > 	spi {

                spi-bus = <&spiN>;
                spi-cs = ...

The base DT would have the spi node and these properties. The overlay 
would still apply to the connector node, but also have the 'spi' node 
along with the devices.

Note that whatever is done here, I expect to work on any connector with 
SPI, I2C, etc. So structuring the bindings for that would be nice. There 
is also this effort which needs the same bindings[1].

> > 		temp-sensor@0 {
> > 			compatible = "maxim,max31855k";
> > 			reg = <0>;
> > 		};
> > 	};
> > 
> > 	i2c {
> > 		..
> > 	};
> > };
> > 
> > I don't think you can introduce a new
> >    compatible = "maxim,max31855k", "mikrobus,spi";
> > if there is already a binding for "maxim,max31855k". But I might be
> > wrong. Why is this compatible needed at all?
> 
> So I did consider the design you just proposed, but I was not able to solve
> a few issues.
> 
> 1. How to deal with say 2 mikrobus connectors in a single system?

I don't understand why that's a problem? It's no different than the same 
overlay working on multiple vendor's boards which I imagine you want 
too. The connector node in the base DT has to remap everything from base 
DT into a mikrobus defined number/name space. For example, host GPIO N 
is mapped to mikrobus connector GPIO 0 and so on.

There is one issue in knowing what the target node is. Standardizing the 
target path or connector node label only works for 1 connector per 
system. You can have an empty target path in the overlay and something 
else can decide the target. This is what's being done for overlays with 
the dynamic PCI nodes. For example, maybe an eeprom tells the driver 
what overlay to apply.

Rob

[1] https://lore.kernel.org/all/20240510-hotplug-drm-bridge-v2-0-ec32f2c66d56@bootlin.com/