linux-kernel - Re: [PATCH v5 2/2] spi: Add generic SPI multiplexer

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: <104152dd-a51e-1893-cc6b-022aecd89250@alliedtelesis.co.nz>
Date:   Tue, 17 Nov 2020 00:08:50 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: Re: [PATCH v5 2/2] spi: Add generic SPI multiplexer


On 14/11/20 4:46 am, Nicolas Saenz Julienne wrote:
> Upon registering spi-mux's devices through spi_add_device() the kernel gets
> stuck waiting for the 'spi_add_lock' mutex to be released. The mutex happens to
> be held by spi-mux's parent SPI bus, which unluckily, is waiting for spi-mux's
> probe to finish before releasing it.

I just re-tested my system with v5.10.0-rc4 and didn't see any problem. 
My dts is pretty similar to yours the only obvious thing missing is 
`mux-control-names = "spi";` and I also set `#size-cells = <1>;` (let me 
know if you want me to post the whole thing).

It might be dependent on the host spi controller. The re-test I just did 
was on a board using the spi-orion.c driver and I tested my original 
change on a board using spi-bcm-qspi.c (I haven't got the board handy 
right now but I could go and find one if necessary).

> I might aswell be doing something wrong. But so far I trust my DT
> implementation:
>
> 	&spi {
> 		status = "okay";
> 		pinctrl-names = "default";
> 		pinctrl-0 = <&spi0_gpio7>;
>
> 		spi@0 {
> 			compatible = "spi-mux";
> 			reg = <0>;
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			spi-max-frequency = <100000000>;
>
> 			mux-controls = <&gpio_mux>;
>
> 			w5500@0 {
> 				compatible = "wiznet,w5500";
> 				reg = <0>;
> 				pinctrl-names = "default";
> 				pinctrl-0 = <&eth1_pins>;
> 				interrupt-parent = <&gpio>;
> 				interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
> 				spi-max-frequency = <30000000>;
> 			};
>
> 			spi-flash@1 {
> 				compatible = "jedec,spi-nor";
> 				reg = <1>;
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 				spi-max-frequency = <16000000>;
> 			};
> 		};
> 	};
>
> Regards,
> Nicolas