Re: [PATCH v7 3/3] mmc: core: Honor keep-power-in-suspend and reset-card-at-resume for (e)MMC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The fast-path in `_mmc_suspend()` for `MMC_POWEROFF_SUSPEND` sets the suspended state but leaves the card powered on. If a shutdown, undervoltage, or unbind event occurs while the card is runtime-suspended, the pre-existing early exit (`if (mmc_card_suspended(host->card)) goto out;`) causes the function to return immediately. This bypasses the critical `mmc_poweroff_notify()` (which sends `EXT_CSD_POWER_OFF_LONG`) and `mmc_power_off()`, directly violating the commit message's claim that these events "still need the normal power-off path".
--

--- Patch [3]: [PATCH v7 3/3] mmc: core: Honor keep-power-in-suspend and reset-card-at-resume for (e)MMC ---
commit 50bf6f999dd980cb9368096f4fc9122b882d9a42
Author: Kamal Dasu <kamal.dasu@broadcom.com>

mmc: core: Honor keep-power-in-suspend and reset-card-at-resume for (e)MMC

This patch introduces support for keep-power-in-suspend and
reset-card-at-resume in the core (e)MMC suspend/resume paths. It adds a
fast-path in _mmc_suspend() that leaves the card powered on if these
capabilities are set, and a corresponding reset block in _mmc_resume().

Link: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli@broadcom.com/

> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 05444ecf3909f..62cc009f2a2bf 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c

[ ... ]

> @@ -2157,6 +2157,33 @@ static int _mmc_suspend(struct mmc_host *host, enum mmc_poweroff_type pm_type)
>  			goto out;
>  	}
>  
> +	/*
> +	 * Keep the card powered across an actual suspend; shutdown, unbind
> +	 * and undervoltage still need the normal power-off path below,
> +	 * since they aren't guaranteed a subsequent _mmc_resume().
> +	 *
> +	 * Check pm_caps, not pm_flags: unlike SDIO, (e)MMC has no
> +	 * per-function driver to request this via
> +	 * sdio_set_host_pm_flags(), so it's a fixed platform trait here.
> +	 *
> +	 * Require MMC_CAP2_RESET_AT_RESUME too: without it, _mmc_resume()
> +	 * has no way to bring the host back to a state mmc_init_card() can
> +	 * use, since mmc_power_up() no-ops when power_mode is already
> +	 * MMC_POWER_ON. Keeping power without also resetting at resume is
> +	 * not a safe combination for this driver.
> +	 */
> +	if (pm_type == MMC_POWEROFF_SUSPEND &&
> +	    (host->pm_caps & MMC_PM_KEEP_POWER) &&
> +	    (host->caps2 & MMC_CAP2_RESET_AT_RESUME)) {
> +		if (!mmc_host_is_spi(host))
> +			err = mmc_deselect_cards(host);
> +		if (!err) {
> +			host->pm_flags |= MMC_PM_KEEP_POWER;
> +			mmc_card_set_suspended(host->card);
> +		}
> +		goto out;
> +	}

[Severity: High]
Does this fast-path interact incorrectly with the early exit at the top of
_mmc_suspend()?

If the host is configured with MMC_PM_KEEP_POWER and MMC_CAP2_RESET_AT_RESUME,
and the eMMC enters runtime suspend, this fast-path marks the card as suspended
but intentionally leaves the power on.

If a subsequent system shutdown, unbind, or undervoltage event occurs,
_mmc_suspend() will be called again. However, since mmc_card_suspended()
is now true, the function will hit the early exit:

	if (mmc_card_suspended(host->card))
		goto out;

Will this bypass mmc_poweroff_notify() and mmc_power_off() entirely,
despite the comment indicating that shutdown, unbind, and undervoltage
still need the normal power-off path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805222500.2567801-1-kamal.dasu@broadcom.com?part=3