* Arnd Bergmann <arnd@xxxxxxxx> [220531 11:38]:
> On Thu, May 5, 2022 at 7:02 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > * Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> [220504 09:12]:
> > > Hi Tony, all,
> > >
> > > During the kernel boot I see the following error. The device is still
> > > working afterwards. 5.17.5 shows the same behavior. Is this a known
> > > issue?
> >
> > Thanks for reporting it, I was not aware of this one. Might be worth
> > bisecting. Adding linux-mmc and Ulf.
> >
> > Regards,
> >
> > Tony
> >
> > > [ 3.734570] sdhci-omap 48060000.mmc: Got CD GPIO
> > > [ 3.739989] INFO: trying to register non-static key.
> > > [ 3.744991] The code is fine but needs lockdep annotation, or maybe
> > > [ 3.751286] you didn't initialize this object before use?
> > > [ 3.756707] turning off the locking correctness validator.
> > > [ 3.762221] CPU: 0 PID: 8 Comm: kworker/u2:0 Not tainted 5.18.0-rc5 #1
> > > [ 3.768787] Hardware name: Generic AM33XX (Flattened Device Tree)
> > > [ 3.774913] Workqueue: events_unbound async_run_entry_fn
> > > [ 3.780283] unwind_backtrace from show_stack+0x10/0x14
> > > [ 3.785555] show_stack from dump_stack_lvl+0x58/0x70
> > > [ 3.790643] dump_stack_lvl from register_lock_class+0x4ec/0x55c
> > > [ 3.796695] register_lock_class from __lock_acquire+0x60/0x2bd4
> > > [ 3.802738] __lock_acquire from lock_acquire.part.0+0xb0/0x248
> > > [ 3.808695] lock_acquire.part.0 from _raw_spin_lock_irqsave+0x4c/0x68
> > > [ 3.815265] _raw_spin_lock_irqsave from sdhci_init+0x34/0xf4
> > > [ 3.821051] sdhci_init from sdhci_runtime_resume_host+0x3c/0x1bc
> > > [ 3.827180] sdhci_runtime_resume_host from
> > > sdhci_omap_runtime_resume+0x108/0x110
> > > [ 3.834710] sdhci_omap_runtime_resume from __rpm_callback+0x3c/0x148
> > > [ 3.841197] __rpm_callback from rpm_callback+0x50/0x54
> > > [ 3.846453] rpm_callback from rpm_resume+0x518/0x71c
> > > [ 3.851534] rpm_resume from __pm_runtime_resume+0x50/0x68
> > > [ 3.857052] __pm_runtime_resume from sdhci_omap_probe+0x1e4/0x7a8
> > > [ 3.863270] sdhci_omap_probe from platform_probe+0x58/0xbc
> > > [ 3.868886] platform_probe from really_probe.part.0+0x9c/0x290
>
> The problem is that sdhci_omap_probe() calls pm_runtime_enable()
> before calling sdhci_setup_host(), so it's not in the correct state at this
> point. One could get rid of the warning by moving the spin_lock_init()
> from sdhci_setup_host() to sdhi_alloc_host(), but I suspect the problem
> is in the omap part, and it would still be wrong to do the resume first.
Yes that makes sense. We need to resume early to detect the hardware
capabilities, we already check the status on first resume for context
save so we can just expand that.
Yegor, care to try to the following patch and see if that works for you?
Regards,
Tony
8< --------------
diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -1441,7 +1441,8 @@ static int __maybe_unused sdhci_omap_runtime_suspend(struct device *dev)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
- sdhci_runtime_suspend_host(host);
+ if (omap_host->con != -EINVAL)
+ sdhci_runtime_suspend_host(host);
sdhci_omap_context_save(omap_host);
@@ -1458,10 +1459,10 @@ static int __maybe_unused sdhci_omap_runtime_resume(struct device *dev)
pinctrl_pm_select_default_state(dev);
- if (omap_host->con != -EINVAL)
+ if (omap_host->con != -EINVAL) {
sdhci_omap_context_restore(omap_host);
-
- sdhci_runtime_resume_host(host, 0);
+ sdhci_runtime_resume_host(host, 0);
+ }
return 0;
}
