On Thu, Oct 07, 2021 at 06:19:46PM +0200, Greg Kroah-Hartman wrote: > On Thu, Oct 07, 2021 at 06:05:24PM +0200, Uwe Kleine-König wrote: > > On an ARM board with an spi-mux I observe a deadlock during boot. This > > happens because spi_add_device() (in drivers/spi/spi.c) for the spi-mux > > device calls device_add() while holding &spi_add_lock. The spi-mux > > driver's probe routine than creates another controller and for the > > devices on that bus spi_add_device() is called again, trying to grab > > &spi_add_lock again. > > > > The easy workaround would be to replace &spi_add_lock with a > > per-controller lock, but I have the expectation that it should be > > possible to not hold a lock while calling device_add(). > > No, busses should not be adding new devices to the same bus from within > a probe function. > > Drivers for a bus bind to the bus, they should not be creating new > devices for that same bus, as that does not seem correct. That's not the culprit here. We have a spi-device (spi-mux) that is a bus device on the SoC's bus and a bus master for it's own bus. And spi_add_device for the spi-mux device triggers the probe function for the spi-mux driver which creates a new bus controller which triggers spi_add_device() for the devices on the inner bus. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
