RE: [PATCH v4 4/7] mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt
"Luke Wang (OSS)" <[email protected]> Mon, 6 Jul 2026 06:21:57 +0000
| Newsgroups | org.kernel.vger.linux-mmc,dev.linux.lists.imx,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <AM7PR04MB6870ECE26A02E0913BB4070BEDF12@AM7PR04MB6870.eurprd04.prod.outlook.com> |
> -----Original Message----- > From: Adrian Hunter <[email protected]> > Sent: Sunday, July 5, 2026 4:30 PM > To: Luke Wang (OSS) <[email protected]>; [email protected]; Bough > Chen <[email protected]>; Frank Li <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; dl-S32 <[email protected]>; > [email protected]; [email protected] > Subject: Re: [PATCH v4 4/7] mmc: sdhci-esdhc-imx: disable irq during > suspend to fix unhandled interrupt > > On 03/07/2026 13:42, [email protected] wrote: > > From: Luke Wang <[email protected]> > > > > When using WIFI out-of-band wakeup, an "irq xxx: nobody cared" warning > > occurs. This happens because the usdhc interrupt is not disabled during > > system suspend when device_may_wakeup() returns false. > > > > The sequence of events leading to this issue: > > 1. System enters suspend without disabling usdhc interrupt > > (because device_may_wakeup() returns false for usdhc device) > > 2. WIFI out-of-band wakeup triggers system resume via GPIO interrupt > > 3. WIFI sends a Card interrupt before usdhc has fully resumed > > 4. usdhc is still in runtime suspend state and cannot handle the > > interrupt properly > > 5. The unhandled interrupt triggers "nobody cared" warning > > > > Fix this by unconditionally disabling the usdhc interrupt during suspend > > and re-enabling it during resume, regardless of the wakeup capability. > > This ensures no interrupts are processed during the suspend/resume > > transition. > > > > Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM > logic") > > Reviewed-by: Haibo Chen <[email protected]> > > Signed-off-by: Luke Wang <[email protected]> > > --- > > drivers/mmc/host/sdhci-esdhc-imx.c | 11 ++++++----- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci- > esdhc-imx.c > > index 3b1e63425a19..ade99dabdb5f 100644 > > --- a/drivers/mmc/host/sdhci-esdhc-imx.c > > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c > > @@ -2075,9 +2075,10 @@ static int sdhci_esdhc_suspend(struct device > *dev) > > if (mmc_card_keep_power(host->mmc) && > esdhc_is_usdhc(imx_data)) > > sdhc_esdhc_tuning_save(host); > > > > + /* The irqs of imx are not shared. It is safe to disable */ > > + disable_irq(host->irq); > > Pre-existing, but IRQ stays disabled even if there is an error later on After patch 6 in this series, all failure paths after disable_irq() were changed from error returns to dev_warn() — the function always reaches pm_runtime_force_suspend() and returns 0. So the IRQ won't be left disabled on an error path. > > > + > > if (device_may_wakeup(dev)) { > > - /* The irqs of imx are not shared. It is safe to disable */ > > - disable_irq(host->irq); > > ret = sdhci_enable_irq_wakeups(host); > > if (!ret) > > dev_warn(dev, "Failed to enable irq wakeup\n"); > > @@ -2128,10 +2129,10 @@ static int sdhci_esdhc_resume(struct device > *dev) > > /* re-initialize hw state in case it's lost in low power mode */ > > sdhci_esdhc_imx_hwinit(host); > > > > - if (host->irq_wake_enabled) { > > + if (host->irq_wake_enabled) > > sdhci_disable_irq_wakeups(host); > > - enable_irq(host->irq); > > - } > > + > > + enable_irq(host->irq); > > Is it OK to enable interrupts before sdhc_esdhc_tuning_restore() > and esdhc_set_dll_override() ? During system resume, the only interrupt that could be pending is the SDIO Card Interrupt. The handler for this just calls sdio_signal_irq() to wake the SDIO IRQ thread — it doesn't involve any data transfer and has no dependency on tuning or DLL settings. I'm happy to move enable_irq() after sdhc_esdhc_tuning_restore() and esdhc_set_dll_override() if you still prefer that for defensive reasons. Thanks, Luke > > > > > /* > > * restore the saved tuning delay value for the device which keep