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.
Attachment:
signature.asc
Description: PGP signature
