RE: [PATCH v4 4/7] mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt

["Luke Wang (OSS)" <ziniu.wang_1@oss.nxp.com>]

> -----Original Message-----
> From: Adrian Hunter <adrian.hunter@intel.com>
> Sent: Sunday, July 5, 2026 4:30 PM
> To: Luke Wang (OSS) <ziniu.wang_1@oss.nxp.com>; ulfh@kernel.org; Bough
> Chen <haibo.chen@nxp.com>; Frank Li <frank.li@nxp.com>
> Cc: s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> imx@lists.linux.dev; linux-mmc@vger.kernel.org; dl-S32 <S32@nxp.com>;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v4 4/7] mmc: sdhci-esdhc-imx: disable irq during
> suspend to fix unhandled interrupt
> 
> On 03/07/2026 13:42, ziniu.wang_1@oss.nxp.com wrote:
> > From: Luke Wang <ziniu.wang_1@nxp.com>
> >
> > 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 <haibo.chen@nxp.com>
> > Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
> > ---
> >  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