All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: ziniu.wang_1@oss.nxp.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH v7 6/8] mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend
Date: Wed, 15 Jul 2026 07:29:58 +0000	[thread overview]
Message-ID: <20260715072959.1404A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715071818.272318-7-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() leads to kernel panic on failure.
--

--- Patch [6]: [PATCH v7 6/8] mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend ---
commit f0a062e3623dc14c66d429be48e9ae36028fd188
Author: Luke Wang <ziniu.wang_1@nxp.com>

mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend

This patch replaces pm_runtime_get_sync() with pm_runtime_resume_and_get() in
sdhci_esdhc_suspend(). It properly returns an error if resuming fails,
preventing a kernel panic caused by accessing hardware registers when the
device is unclocked.

> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 6e792bee25bfa..ec531a9451c4e 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -2061,7 +2061,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, but since the commit message notes that accessing
hardware registers while the device is unclocked causes a kernel panic, could
this same panic occur in sdhci_esdhc_imx_remove()?

Looking at the device removal path:

drivers/mmc/host/sdhci-esdhc-imx.c:sdhci_esdhc_imx_remove() {
	...
	pm_runtime_get_sync(&pdev->dev);
	dead = (readl(host->ioaddr + SDHCI_INT_STATUS) == 0xffffffff);
	...
}

If pm_runtime_get_sync() fails to resume the device here, execution proceeds to
readl() on the unclocked hardware. Should we also use
pm_runtime_resume_and_get() and check the return value in the remove path to
avoid a panic during unbind?

>  
>  	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/20260715071818.272318-1-ziniu.wang_1@oss.nxp.com?part=6

  reply	other threads:[~2026-07-15  7:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15  7:18 [PATCH v7 0/8] mmc: sdhci-esdhc-imx: fix SDIO suspend/resume issues ziniu.wang_1
2026-07-15  7:18 ` [PATCH v7 1/8] mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check for tuning save/restore ziniu.wang_1
2026-07-15  7:29   ` sashiko-bot
2026-07-15  7:18 ` [PATCH v7 2/8] mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume ziniu.wang_1
2026-07-15  7:32   ` sashiko-bot
2026-07-15  7:18 ` [PATCH v7 3/8] mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restore ziniu.wang_1
2026-07-15  7:18 ` [PATCH v7 4/8] mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on resume ziniu.wang_1
2026-07-15  7:32   ` sashiko-bot
2026-07-15  7:18 ` [PATCH v7 5/8] mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt ziniu.wang_1
2026-07-15  7:18 ` [PATCH v7 6/8] mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend ziniu.wang_1
2026-07-15  7:29   ` sashiko-bot [this message]
2026-07-15  7:18 ` [PATCH v7 7/8] mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking " ziniu.wang_1
2026-07-15  7:27   ` sashiko-bot
2026-07-15  7:18 ` [PATCH v7 8/8] mmc: sdhci-esdhc-imx: fix resume error handling ziniu.wang_1
2026-07-15  7:41   ` sashiko-bot
2026-07-15  9:08 ` [PATCH v7 0/8] mmc: sdhci-esdhc-imx: fix SDIO suspend/resume issues Ulf Hansson

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=20260715072959.1404A1F000E9@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.