On Tue, Nov 17, 2020 at 12:45:17PM +0300, Serge Semin wrote:

> method being called at the same time. In particular in calling the
> spi_set_cs(false) while there is an SPI-transfer being executed. In my
> case due to the commit cited above all CSs get to be switched off by
> calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
> SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
> of the spi_setup() being called while there is an SPI-transfer being
> executed for two different SPI peripheral devices of the same controller
> may happen not only for the spidev driver, but for instance for MMC SPI +
> some another device, or spi_setup() being called from an SPI-peripheral
> probe method while some other device has already been probed and is being
> used by a corresponding driver...

It's documented that a driver's spi_setup() operation is supposed to
support being able to be called concurrently with other transfers, see
spi-summary.rst.

> Of course I could have provided a fix affecting the DW APB SSI driver
> only, for instance, by creating a mutual exclusive access to the set_cs
> callback and setting/clearing only the bit responsible for the
> corresponding chip-select. But after a short research I've discovered that
> the problem most likely affects a lot of the other drivers:

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.