Re: [PATCH v7 7/8] mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The return value of `pm_runtime_force_suspend()` is ignored during system suspend, which can cause a kernel warning and a potential fatal crash on system resume if the suspend operation fails.
--

--- Patch [7]: [PATCH v7 7/8] mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend ---
commit 343530f069b563d297215c212283dc394ffae3fd
Author: Luke Wang <ziniu.wang_1@nxp.com>

mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend

This commit modifies the suspend path to ensure that failures from certain
wakeup and pinctrl functions do not block the system suspend process. It
accomplishes this by treating these failures as non-fatal warnings and
always returning success.

> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c

[ ... ]

> @@ -2108,7 +2107,7 @@ static int sdhci_esdhc_suspend(struct device *dev)
>  	 */
>  	pm_runtime_force_suspend(dev);
>  
> -	return ret;
> +	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but is it safe to ignore the return value of
pm_runtime_force_suspend() here?

If the driver's runtime suspend callback fails (for instance, due to a
cqhci_suspend error), pm_runtime_force_suspend() will return an error and
leave the device in the active state.

By returning 0 regardless of whether pm_runtime_force_suspend() succeeded,
the PM core is led to believe the device suspended successfully. On system
resume, pm_runtime_force_resume() would see the device is still active and
skip calling the runtime_resume callback.

Since the runtime_resume callback enables the clocks, skipping it means the
subsequent call to sdhci_esdhc_imx_hwinit() will attempt to access hardware
registers without clocks enabled. If the power domain was turned off during
sleep, wouldn't this unclocked register access trigger a synchronous external
abort and kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715071818.272318-1-ziniu.wang_1@oss.nxp.com?part=7