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/ |