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