Devicetree
 help / color / mirror / Atom feed
* [PATCH v3 0/2] mmc: core: Keep the card powered across suspend when firmware needs it live
@ 2026-07-22 21:14 Kamal Dasu
  2026-07-22 21:14 ` [PATCH v3 1/2] dt-bindings: mmc: Document no-mmc-poweroff-suspend property Kamal Dasu
  2026-07-22 21:14 ` [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability Kamal Dasu
  0 siblings, 2 replies; 4+ messages in thread
From: Kamal Dasu @ 2026-07-22 21:14 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Kamal Dasu, Florian Fainelli, Wolfram Sang, Oleksij Rempel,
	Avri Altman, Pedro Demarchi Gomes, Erick Shepherd, Adrian Hunter,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
	devicetree, linux-kernel

This is v3, following Ulf's review of v2:

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

Background: on brcmstb boards with a Kioxia 016G01 eMMC, firmware
accesses the card directly during resume from Suspend-to-DRAM, before
the kernel's own resume path runs, in order to load boot code using
hard wired logic that is not field updatable. The card needs to stay
powered and responsive for that access to succeed.

Changes in v3:
  - Reworked the fix in _mmc_suspend() (drivers/mmc/core/mmc.c) to
    skip the poweroff-notify/sleep/power-off sequence entirely.
  - Renamed no-mmc-sleep/MMC_CAP2_NO_SLEEP_CMD to
    no-mmc-poweroff-suspend/MMC_CAP2_NO_POWEROFF_SUSPEND.

Changes in v2:
  - Replaced v1's card-level MMC_QUIRK_BROKEN_SLEEP quirk with a host
    capability and matching DT property, per Ulf's suggestion.
  - Added Reported-by/Closes tags crediting Florian.

Kamal Dasu (2):
  dt-bindings: mmc: Document no-mmc-poweroff-suspend property
  mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability

 .../bindings/mmc/mmc-controller-common.yaml       | 10 ++++++++++
 drivers/mmc/core/host.c                           |  2 ++
 drivers/mmc/core/mmc.c                            | 15 +++++++++++++++
 include/linux/mmc/host.h                          |  1 +
 4 files changed, 28 insertions(+)

-- 
2.34.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH v3 1/2] dt-bindings: mmc: Document no-mmc-poweroff-suspend property
  2026-07-22 21:14 [PATCH v3 0/2] mmc: core: Keep the card powered across suspend when firmware needs it live Kamal Dasu
@ 2026-07-22 21:14 ` Kamal Dasu
  2026-07-22 21:14 ` [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability Kamal Dasu
  1 sibling, 0 replies; 4+ messages in thread
From: Kamal Dasu @ 2026-07-22 21:14 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Kamal Dasu, Florian Fainelli, Wolfram Sang, Oleksij Rempel,
	Avri Altman, Pedro Demarchi Gomes, Erick Shepherd, Adrian Hunter,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
	devicetree, linux-kernel

On some platforms, firmware accesses the (e)MMC card directly during
system resume from Suspend-to-DRAM, before the kernel's own resume
path has run, in order to load boot code using hard wired logic that
is not field updatable. This requires the card to remain powered
and responsive throughout suspend: it cannot be put to sleep, sent a
power-off notification, or have its supply removed.

Add a no-mmc-poweroff-suspend flag property so affected boards can
tell the mmc core to keep the card powered across suspend instead of
sleeping or powering it off.

Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
---
Changes in v3:
  - Renamed from no-mmc-sleep; dropped S_A_TIMEOUT framing per Ulf.

Changes in v2:
  - New patch, replacing v1's card-level quirk, per Ulf.

 .../devicetree/bindings/mmc/mmc-controller-common.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 3d7195e9461c..5f7b3f8ef1dd 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -232,6 +232,16 @@ properties:
     description:
       All eMMC HS400 modes are not supported.
 
+  no-mmc-poweroff-suspend:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      On this platform, firmware accesses the attached (e)MMC card
+      directly during system resume, before the kernel's own resume
+      path runs. The card must therefore stay powered throughout
+      suspend, and the controller must not send it a sleep or
+      power-off notification. The kernel re-initializes the card
+      after resume, since firmware may have already reset it.
+
   dsr:
     description:
       Value the card Driver Stage Register (DSR) should be programmed
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability
  2026-07-22 21:14 [PATCH v3 0/2] mmc: core: Keep the card powered across suspend when firmware needs it live Kamal Dasu
  2026-07-22 21:14 ` [PATCH v3 1/2] dt-bindings: mmc: Document no-mmc-poweroff-suspend property Kamal Dasu
@ 2026-07-22 21:14 ` Kamal Dasu
  2026-07-22 21:24   ` sashiko-bot
  1 sibling, 1 reply; 4+ messages in thread
From: Kamal Dasu @ 2026-07-22 21:14 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Kamal Dasu, Florian Fainelli, Wolfram Sang, Oleksij Rempel,
	Avri Altman, Pedro Demarchi Gomes, Erick Shepherd, Adrian Hunter,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
	devicetree, linux-kernel

On some platforms, firmware accesses the (e)MMC card directly during
resume from Suspend-to-DRAM, before the kernel's own resume path has
run, in order to load boot code. This requires the card to remain
powered and responsive throughout suspend: putting it to sleep,
sending it a power-off notification, or removing its supply is not
safe, since firmware needs to talk to a live card.

Add MMC_CAP2_NO_POWEROFF_SUSPEND, settable via the new
"no-mmc-poweroff-suspend" DT property. In _mmc_suspend(), when this
capability is set, skip the poweroff-notify/sleep/power-off sequence
entirely: just deselect the card and mark it suspended. At resume,
_mmc_resume() already unconditionally calls mmc_power_up() and
mmc_init_card(), so the card gets fully re-initialized regardless of
what firmware may have done to it in the meantime.

Reported-by: Florian Fainelli <florian.fainelli@broadcom.com>
Closes: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli@broadcom.com/
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
---
Changes in v3:
  - Reworked _mmc_suspend() to skip poweroff-notify/sleep/power-off
    entirely, not just SLEEP, per Ulf.
  - Renamed to MMC_CAP2_NO_POWEROFF_SUSPEND/no-mmc-poweroff-suspend.

Changes in v2:
  - Replaced the card-level MMC_QUIRK_BROKEN_SLEEP quirk with a host
    capability, per Ulf.
  - Added Reported-by/Closes crediting Florian.

 drivers/mmc/core/host.c  |  2 ++
 drivers/mmc/core/mmc.c   | 15 +++++++++++++++
 include/linux/mmc/host.h |  1 +
 3 files changed, 18 insertions(+)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index b7ce3137d452..35fd0be99c58 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -400,6 +400,8 @@ int mmc_of_parse(struct mmc_host *host)
 	if (device_property_read_bool(dev, "no-mmc-hs400"))
 		host->caps2 &= ~(MMC_CAP2_HS400_1_8V | MMC_CAP2_HS400_1_2V |
 				 MMC_CAP2_HS400_ES);
+	if (device_property_read_bool(dev, "no-mmc-poweroff-suspend"))
+		host->caps2 |= MMC_CAP2_NO_POWEROFF_SUSPEND;
 
 	/* Must be after "non-removable" check */
 	if (device_property_read_u32(dev, "fixed-emmc-driver-type", &drv_type) == 0) {
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 05444ecf3909..27a559e6fcc0 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -2157,6 +2157,21 @@ static int _mmc_suspend(struct mmc_host *host, enum mmc_poweroff_type pm_type)
 			goto out;
 	}
 
+	/*
+	 * Some platforms need the card to stay powered and responsive
+	 * throughout suspend, since firmware accesses it directly during
+	 * resume, before the kernel's own resume path has run. Just
+	 * deselect it and leave power alone; mmc_init_card() will fully
+	 * re-initialize the card once the kernel resumes.
+	 */
+	if (host->caps2 & MMC_CAP2_NO_POWEROFF_SUSPEND) {
+		if (!mmc_host_is_spi(host))
+			err = mmc_deselect_cards(host);
+		if (!err)
+			mmc_card_set_suspended(host->card);
+		goto out;
+	}
+
 	if (mmc_card_can_poweroff_notify(host->card) &&
 	    mmc_host_can_poweroff_notify(host, pm_type))
 		err = mmc_poweroff_notify(host->card, notify_type);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba84f02c2a10..e082aab8f4c4 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -463,6 +463,7 @@ struct mmc_host {
 #define MMC_CAP2_CRYPTO		0
 #endif
 #define MMC_CAP2_ALT_GPT_TEGRA	(1 << 28)	/* Host with eMMC that has GPT entry at a non-standard location */
+#define MMC_CAP2_NO_POWEROFF_SUSPEND (1 << 29)	/* Card must stay powered across suspend */
 
 	bool			uhs2_sd_tran;	/* UHS-II flag for SD_TRAN state */
 	bool			uhs2_app_cmd;	/* UHS-II flag for APP command */
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability
  2026-07-22 21:14 ` [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability Kamal Dasu
@ 2026-07-22 21:24   ` sashiko-bot
  0 siblings, 0 replies; 4+ messages in thread
From: sashiko-bot @ 2026-07-22 21:24 UTC (permalink / raw)
  To: Kamal Dasu; +Cc: devicetree, robh, conor+dt

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The MMC_CAP2_NO_POWEROFF_SUSPEND bypass unconditionally applies to all power-off types in `_mmc_suspend()`, preventing power-off notifications and emergency actions during system shutdown, driver unbind, and undervoltage protection.
- [High] Skipping `mmc_power_off` during suspend leaves `host->ios.power_mode` as `MMC_POWER_ON`, causing `mmc_power_up` to return early on resume, which breaks card re-initialization by failing to reset the clock and bus state.
--

--- Patch [2]: [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability ---
commit d167c50cff315ae6b0704bc19e48556178313b8a
Author: Kamal Dasu <kamal.dasu@broadcom.com>

mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability

On some platforms, firmware accesses the (e)MMC card directly during resume
from Suspend-to-DRAM. This requires the card to remain powered and responsive
throughout suspend. This patch adds MMC_CAP2_NO_POWEROFF_SUSPEND to skip the
poweroff-notify/sleep/power-off sequence during _mmc_suspend().

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..27a559e6fcc0b 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -2157,6 +2157,21 @@ static int _mmc_suspend(struct mmc_host *host, enum mmc_poweroff_type pm_type)
>  			goto out;
>  	}
>  
> +	/*
> +	 * Some platforms need the card to stay powered and responsive
> +	 * throughout suspend, since firmware accesses it directly during
> +	 * resume, before the kernel's own resume path has run. Just
> +	 * deselect it and leave power alone; mmc_init_card() will fully
> +	 * re-initialize the card once the kernel resumes.
> +	 */
> +	if (host->caps2 & MMC_CAP2_NO_POWEROFF_SUSPEND) {

[Severity: High]
Does this unconditionally bypass the power-off and notification sequence for
all pm_type values, including MMC_POWEROFF_SHUTDOWN and 
MMC_POWEROFF_UNDERVOLTAGE?

Since this doesn't check if pm_type == MMC_POWEROFF_SUSPEND, could this
prevent required power-off notifications and emergency actions during system
shutdown, driver unbind, or undervoltage events?

[Severity: High]
If we skip mmc_power_off() here, won't host->ios.power_mode remain
MMC_POWER_ON?

During resume, _mmc_resume() calls mmc_power_up(), which checks the
power_mode:

drivers/mmc/core/core.c:mmc_power_up() {
    if (host->ios.power_mode == MMC_POWER_ON)
        return;
    ...
}

Will mmc_power_up() return early, skipping the clock and bus reset in
mmc_set_initial_state()?

If so, could this cause mmc_init_card() to subsequently execute using an
invalid high-speed host bus state instead of the required reset state?

> +		if (!mmc_host_is_spi(host))
> +			err = mmc_deselect_cards(host);
> +		if (!err)
> +			mmc_card_set_suspended(host->card);
> +		goto out;
> +	}
> +
>  	if (mmc_card_can_poweroff_notify(host->card) &&
>  	    mmc_host_can_poweroff_notify(host, pm_type))
>  		err = mmc_poweroff_notify(host->card, notify_type);

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-07-22 21:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-22 21:14 [PATCH v3 0/2] mmc: core: Keep the card powered across suspend when firmware needs it live Kamal Dasu
2026-07-22 21:14 ` [PATCH v3 1/2] dt-bindings: mmc: Document no-mmc-poweroff-suspend property Kamal Dasu
2026-07-22 21:14 ` [PATCH v3 2/2] mmc: core: Add MMC_CAP2_NO_POWEROFF_SUSPEND host capability Kamal Dasu
2026-07-22 21:24   ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox