[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2b7f555bee663a033e2e8fc50f019c9b580a7c66.camel@suse.de>
Date: Fri, 20 Nov 2020 17:18:50 +0100
From: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
"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 Tue, 2020-11-17 at 00:08 +0000, Chris Packham wrote:
> 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).
Found the issue, something silly on my side. Sorry for the noise.
Regards,
Nicolas
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists