[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201119184340.GJ5554@sirena.org.uk>
Date: Thu, 19 Nov 2020 18:43:40 +0000
From: Mark Brown <broonie@...nel.org>
To: Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc: Serge Semin <fancer.lancer@...il.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method
On Wed, Nov 18, 2020 at 07:29:31PM +0300, Serge Semin wrote:
> On Wed, Nov 18, 2020 at 01:16:04PM +0000, Mark Brown wrote:
> > Yeah, problems with it are very common as the documentation has noted
> > since forever. IIRC there was some problem triggered by trying to force
> > it to be serialised but I can't remember what it was.
> Does it mean nack for this patch from you? So you suggest to fix the controller
> driver instead, right? If so the best solution would be to just lock the
> IO mutex in the set_cs callback of the DW APB SSI driver...
I'm not 100% clear what the original issue was, given that this is a
constant source of errors in drivers it seems like it should be better
to change the core but since I don't know why we have this the way it is
it's hard to tell what special cases we might have that could explode if
we try to do so. I *think* the main issue is things that don't actually
have separate per device registers trying to configure the single set of
controler registers shared by all devices in which case the locking is
fine and helps with this specific case where it's a read/modify/write
operation on per device stuff and this makes sense.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists