Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

[Geert Uytterhoeven]

Hi Mark,

On Thu, Nov 19, 2020 at 7:45 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
> 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.

It's also an issue on SPI controllers with a single native chipselect,
tricking the driver author into believing that writing to registers
during .setup() is not an issue.  Until an integrator starts using
cs-gpios...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds