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]

Message-Id: <D2AZMD2YYGAQ.1B3AGXIC7B44@kernel.org>
Date: Thu, 27 Jun 2024 19:49:17 +0200
From: "Michael Walle" <mwalle@...nel.org>
To: "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>
Cc: <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

Hi,

On Thu Jun 27, 2024 at 7:29 PM CEST, 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
> >
> > 	spi {
> > 		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?

Yes, interesting problem. That info should go into the cover letter.

> My goal is to have only 1 overlay required for the board config at most. 
> Ideally, I would actually like to add the dt for most mikroBUS boards to 
> upstream and thus only the following overlay would be required:
>
> ```
>
> &connector0 {
>
>      board = <&temp-board>;
>
> };

That's then per board, per click board. right?

>
> ```
>
>
> The problem with making it children is that each connector will require 
> seperate overlays for board configs.

Right.

> Additionally, there are boards with 1 wire eeprom available which can 
> theselves store the overlay. In the current setup it will look as follows:
>
> ```
>
> &mikrobus_board {

Where is that phandle pointing to? And what if there are two boards?

>
>      thermo-sensor {
>
>          ...
>
>      };
>
> };

But here you can have subnodes, no? These could then be just
enumerated as usual.

&mikrobus_board {
	mikrobus_gpio: gpio {
		gpio-controller;
		#gpio-cells = <1>;
	};

	spi {
		cs-gpios = <&mikrobus_gpio 1>;

		spi@0 {
			compatible = "mydevice";
			reg = <0>;
		};
	};
};


> ```

Not sure what this is, but my mail reader doesn't render RST? ;)

-michael

>
> Which is completely independent of the connector. If the same can be 
> achieved with child-node as well, then I am open to doing that.
>
>
> >
> > Also, the mikrobus-connector driver could translate the chipselects.
> >
> > -michael
>
> Yes, so it is currently doing that. Translating chip select name to the 
> actual number. I am doing it the name way since some boards might use 
> pins other than CS as chipselect and not all connectors will allow all 
> pins to be used as chipselect.
>
>
> Ayush Singh