linux-kernel - Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <30f2f62406bab8225cc88013b414016d@walle.cc>
Date:   Thu, 21 Apr 2022 17:16:40 +0200
From:   Michael Walle <michael@...le.cc>
To:     Rob Herring <robh@...nel.org>
Cc:     krzysztof.kozlowski@...aro.org, broonie@...nel.org,
        devicetree@...r.kernel.org, jerry.huang@....com,
        krzysztof.kozlowski+dt@...aro.org, leoyang.li@....com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-spi@...r.kernel.org, shawnguo@...nel.org,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech
 sx1301

Am 2022-04-21 16:23, schrieb Rob Herring:

> What's needed here is a connector node (and driver) for the mikrobus
> socket. The connector node's purpose is to decouple the host DT from
> add-on board overlay DT. Something like this:

Funny I had a similar idea to have a connector with all the
properties, but I failed to see how that would be of any help.

Do you mind an example of such an overlay? Judging by the spi
and i2c subnode, I guess it will amend the connector node and
fill in it's devices?

And all the child device properties will reference the connector,
correct?

> connector {
> 	// And a more specific compatible if pins can have alt funcs?
> 	// Spec version needed?
> 	compatible = "mikrobus-socket";
> 
> 	// Will need regulators defined if child devices expect
> 	// regulators
> 	vcc-33-supply = <&reg33>;
> 	vcc-5-supply = <&reg5v>;
> 
> 	i2c-parent = <&i2c1>; // Already a defined property
> 	spi-parent = <&spi0>; // New

uart/serial needed too?

> 
> 	// RST pin
> 	reset-gpios = <&gpio 4 0>;
> 
> 	// remap 'INT' (index 0) to host interrupt
> 	#interrupt-cells = <2>;
> 	#address-cells = <0>;
> 	interrupt-map = <0 0 &gpio 3 0>;
> 
> 	spi {

For example:

my-device@0 {
   reg = <0>;  // really needed? there is only one SPI CS line
   compatible = "my-device";
   reset-gpios = // may be left unset if it's optional, but what
                 // what if it is a required property and in hardware
                 // its connected to the RST pin of the module?
   other-gpios = <&connector 2>;
   vdd-supply = // what comes here? <&connector VCC_33>?
   interrupts-extended = <&connector 0 ..>;
}

-michael

> 		//devices
> 	};
> 
> 	i2c {
> 
> 	};
> };
> 
> The DT spec defines 'foo-map' properties extending interrupt-map.
> Currently only GPIO is defined. We might want to do the same thing for
> PWM. Or we make the connector node both a PWM consumer and provider.
> 
> Rob