linux-kernel - Re: [PATCH 1/3] dt-bindings: spi: Add spi-mux-gpio

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] [day] [month] [year] [list]

Message-ID: <58e3dcf5cf69fa5fda6f887dc442fec4d9901ffd.camel@alliedtelesis.co.nz>
Date:   Mon, 13 Jan 2020 03:43:39 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "robh@...nel.org" <robh@...nel.org>
CC:     "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "anthony.derosa@...call7.com" <anthony.derosa@...call7.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 1/3] dt-bindings: spi: Add spi-mux-gpio

Hi Rob,

On Mon, 2019-04-29 at 16:37 -0500, Rob Herring wrote:
> On Fri, Apr 12, 2019 at 05:02:11PM +1200, Chris Packham wrote:
> > Add binding documentation for spi-mux-gpio which is a slightly more
> > complicated hardware implementation of using gpios to steer SPI chip
> > selects.
> > 
> > Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> > ---
> >  .../devicetree/bindings/spi/spi-mux-gpio.txt  | 45 +++++++++++++++++++
> >  1 file changed, 45 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/spi/spi-mux-gpio.txt b/Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
> > new file mode 100644
> > index 000000000000..a32f25321d37
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
> > @@ -0,0 +1,45 @@
> > +SPI bus gpio multiplexer
> > +
> > +The SPI bus gpio multiplexer can be used to implement more complicated access
> > +logic than can be supported with the cs-gpios property of a SPI bus.
> > +
> > +In the example below we have a SoC with a single SPI CS that is gated by the
> > +state of a gpio to select the desired SPI device.
> > +
> > +     +----------+  CS    +-----+ CS0  +----+
> > +     |          |--------|     |------|    |
> > +     |          |        | \ / |      +----+
> > +     |   SoC    |        |  +  |
> > +     |          |  GPIO  | / \ | CS1  +----+
> > +     |          |--------|     |------|    |
> > +     +----------+        +-----+      +----+
> > +
> > +Required properties:
> > +- compatible	- must be "spi-mux-gpio"
> > +- gpios		- gpios used to implement the multiplexing logic
> > +- spi-parent-bus - parent spi bus to use
> > +
> > +Optional properties:
> > +- spi-parent-cs - chip select on parent bus to use. Defaults to 0 if not
> > +                  specified.
> > +
> > +Example for a multiplexer with a single gpio:
> > +
> > +	spi-mux {
> > +		compatible = "spi-mux-gpio";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		gpios = <&gpio0 1 0>;
> > +		spi-parent-bus = <&spi0>;
> > +		spi-parent-cs = <0>;
> 
> Why is this out of band? We can do something similar to I2C and use the 
> mux-control binding:
> 
> spi {
> 	mux@0 {
> 		compatible = "spi-mux";
> 		reg "0"; 
> 		mux-controls = ...;
> 
> 		spi-dev@0 {};
> 		spi-dev@1 {};
> 	};
> 
> 	spi-dev@1 {};
> 
> };

I've been re-visiting this thread and an older one[1] with an eye on
implementing a solution with mux-controls.

One thing I'm confused about is your comment that the mux should be in-
band like i2c. Looking at the one user of i2c-mux (at91-natte.dtsi) it
also appears out of band and determine the parent bus with a i2c-parent 
property (similar to how I did it in my original submission). I also
can't see how the mux would work in-band since it lacks the correct
#address-cells etc for a spi device.

I'm wondering if I've missed something obvious.

--
[1] - https://patchwork.kernel.org/patch/2706151/