Messages in this thread | | | Date | Wed, 18 Nov 2020 13:16:04 +0000 | From | Mark Brown <> | Subject | Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method |
| |
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. [unhandled content-type:application/pgp-signature] | |