From: sashiko-bot@kernel.org
To: ziniu.wang_1@oss.nxp.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH v4 5/7] mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend
Date: Fri, 03 Jul 2026 11:18:33 +0000 [thread overview]
Message-ID: <20260703111833.CE0931F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260703104208.3426374-6-ziniu.wang_1@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unchecked `pm_runtime_get_sync()` in `sdhci_esdhc_imx_remove()` can lead to unclocked hardware register access and a kernel panic.
--
commit 27f08d0dd0a0d98186f1636e70aa4e0a00112c22
Author: Luke Wang <ziniu.wang_1@nxp.com>
mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend
This patch replaces a call to pm_runtime_get_sync() with
pm_runtime_resume_and_get() during device suspend to simplify error handling.
It ensures that if the resume fails, the driver returns immediately instead
of proceeding to access unclocked hardware registers which would cause a
kernel panic.
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index ade99dabdb5fd..30aef7bc1fc67 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -2059,7 +2059,9 @@ static int sdhci_esdhc_suspend(struct device *dev)
> * 2, make sure the pm_runtime_force_resume() in sdhci_esdhc_resume() really
> * invoke its ->runtime_resume callback (needs_force_resume = 1).
> */
> - pm_runtime_get_sync(dev);
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
[Severity: High]
This is a pre-existing issue, and not a bug introduced by this patch, but
since you are fixing unchecked runtime PM calls here, could a similar panic
happen during device removal?
Looking at sdhci_esdhc_imx_remove(), there is an unchecked call to
pm_runtime_get_sync() right before reading from the hardware:
sdhci_esdhc_imx_remove() {
...
pm_runtime_get_sync(&pdev->dev);
dead = (readl(host->ioaddr + SDHCI_INT_STATUS) == 0xffffffff);
...
}
If the runtime resume fails in the removal path, the clocks would remain
disabled.
Would the subsequent readl() trigger a bus fault for the same reason?
Should we add error handling or switch to pm_runtime_resume_and_get() in
sdhci_esdhc_imx_remove() as well?
>
> if ((imx_data->socdata->flags & ESDHC_FLAG_STATE_LOST_IN_LPMODE) &&
> (host->tuning_mode != SDHCI_TUNING_MODE_1)) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703104208.3426374-1-ziniu.wang_1@oss.nxp.com?part=5
next prev parent reply other threads:[~2026-07-03 11:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 10:42 [PATCH v4 0/7] mmc: sdhci-esdhc-imx: fix SDIO suspend/resume issues ziniu.wang_1
2026-07-03 10:42 ` [PATCH v4 1/7] mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check for tuning save/restore ziniu.wang_1
2026-07-05 8:48 ` Adrian Hunter
2026-07-03 10:42 ` [PATCH v4 2/7] mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume ziniu.wang_1
2026-07-05 8:49 ` Adrian Hunter
2026-07-03 10:42 ` [PATCH v4 3/7] mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing " ziniu.wang_1
2026-07-03 11:12 ` sashiko-bot
2026-07-05 8:14 ` Adrian Hunter
2026-07-06 3:25 ` Luke Wang (OSS)
2026-07-03 10:42 ` [PATCH v4 4/7] mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt ziniu.wang_1
2026-07-05 8:30 ` Adrian Hunter
2026-07-06 6:21 ` Luke Wang (OSS)
2026-07-03 10:42 ` [PATCH v4 5/7] mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend ziniu.wang_1
2026-07-03 11:18 ` sashiko-bot [this message]
2026-07-03 10:42 ` [PATCH v4 6/7] mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking " ziniu.wang_1
2026-07-03 10:42 ` [PATCH v4 7/7] mmc: sdhci-esdhc-imx: fix resume error handling ziniu.wang_1
2026-07-03 11:32 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260703111833.CE0931F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=ziniu.wang_1@oss.nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.