Hi, On Feb 26, 2024 at 13:40:00 +0000, Mark Brown wrote: > On Mon, Feb 26, 2024 at 01:27:57PM +0000, Mark Brown wrote: > > On Mon, Feb 26, 2024 at 05:48:03PM +0530, Dhruva Gole wrote: > > > On Feb 22, 2024 at 19:13:29 +0000, Mark Brown wrote: > > > [ 1.709414] Call trace: > > [ 1.711852] __mutex_lock.constprop.0+0x84/0x540 > > [ 1.716460] __mutex_lock_slowpath+0x14/0x20 > > [ 1.720719] mutex_lock+0x48/0x54 > > [ 1.724026] spi_controller_suspend+0x30/0x7c > > [ 1.728377] cqspi_suspend+0x1c/0x6c > > [ 1.731944] pm_generic_runtime_suspend+0x2c/0x44 > > [ 1.736640] genpd_runtime_suspend+0xa8/0x254 > > > (it's generally helpful to provide the most relevant section directly.) > > > The issue here appears to be that we've registered for runtime suspend > > prior to registering the controller... > > Actually, no - after this series cqspi_suspend() is the system not > runtime PM operation and should not be called from runtime suspend. How > is that happening? I tried dropping this entire series, it doesn't really solve the kernel boot issues. Also this particular stack dump isn't easily reproducible either. Perhaps this series may not be the rootcause, I will need some more time to see what's breaking boot for us. But for now this series seems to be in the clear. Will keep you posted if I find anything funny here. FYI- We're just using the arm64 defconfig and respective device DTs -- Best regards, Dhruva Gole <d-gole@xxxxxx>