On Fri, May 15, 2020 at 7:41 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Fri, May 15, 2020 at 05:27:25PM +0100, Mark Brown wrote: > > On Fri, May 15, 2020 at 05:58:01PM +0200, Lukas Wunner wrote: > > > However since commit ffbbdd21329f ("spi: create a message queueing > > > infrastructure"), spi_destroy_queue() is executed before unbinding the > > > slaves. It sets ctlr->running = false, thereby preventing SPI bus > > > access and causing unbinding of slave devices to fail. > > > > Devices should basically never fail an unbind operation - if something > > went seriously wrong there's basically nothing that can be done in terms > > of error handling and keeping the device around isn't going to help. > > I guess the word "fail" in the commit message invites misinterpretations. > The driver does unbind from the slave device, but the physical device is > not left in a proper state. E.g. interrupts may still be generated by > the device because writing a register to disable them failed. I didn't check a patch, but I see a bug on kernel bugzilla against spi-pxa2xx because of this. It requires quite untrivial ->remove() in order to quiescent the DMA and other activities. -- With Best Regards, Andy Shevchenko