* [PATCH v2 1/2] dt-bindings: mmc: Document no-mmc-sleep property
2026-07-17 18:05 [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume Kamal Dasu
@ 2026-07-17 18:05 ` Kamal Dasu
2026-07-18 13:44 ` Ulf Hansson
2026-07-17 18:05 ` [PATCH v2 2/2] mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability Kamal Dasu
2026-07-18 13:32 ` [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume Ulf Hansson
2 siblings, 1 reply; 6+ messages in thread
From: Kamal Dasu @ 2026-07-17 18:05 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
Some (e)MMC devices cannot reliably resume from the SLEEP (CMD5)
state within their advertised S_A_TIMEOUT, which can be problematic
on systems that resume from Suspend-to-DRAM by first pulling boot
code from eMMC using hard wired logic that is not field updatable.
Add a no-mmc-sleep flag property so affected boards can tell the
mmc core to never put the card to sleep.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
---
Changes in v2:
- New patch. v1 used a card-level MMC_QUIRK_BROKEN_SLEEP quirk
instead of a DT property; this documents the DT property backing
the host capability added in patch 2, per Ulf's suggestion.
- Reworded the rationale in the commit message and the binding
description per Florian's review.
.../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 3d7195e9461c..11df0524530c 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -232,6 +232,14 @@ properties:
description:
All eMMC HS400 modes are not supported.
+ no-mmc-sleep:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The attached (e)MMC card cannot reliably resume from the SLEEP
+ (CMD5) state within its advertised S_A_TIMEOUT, so the
+ controller must not put it to sleep during suspend or power
+ off.
+
dsr:
description:
Value the card Driver Stage Register (DSR) should be programmed
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v2 1/2] dt-bindings: mmc: Document no-mmc-sleep property
2026-07-17 18:05 ` [PATCH v2 1/2] dt-bindings: mmc: Document no-mmc-sleep property Kamal Dasu
@ 2026-07-18 13:44 ` Ulf Hansson
0 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2026-07-18 13:44 UTC (permalink / raw)
To: Kamal Dasu
Cc: Ulf Hansson, 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 Fri, Jul 17, 2026 at 8:06 PM Kamal Dasu <kamal.dasu@broadcom.com> wrote:
>
> Some (e)MMC devices cannot reliably resume from the SLEEP (CMD5)
> state within their advertised S_A_TIMEOUT, which can be problematic
> on systems that resume from Suspend-to-DRAM by first pulling boot
> code from eMMC using hard wired logic that is not field updatable.
> Add a no-mmc-sleep flag property so affected boards can tell the
> mmc core to never put the card to sleep.
Please clarify what the FW is doing in the commit message so we can
better understand what is needed. Along the lines of the below.
Moreover, as stated for the cover letter; this is rather about keeping
the card powered on during system suspend, because of the behaviour in
the FW.
Moreover, because of the behaviour in the FW, the kernel still needs
to re-initialize the card at system resume.
In regards to the card advertising a wrong S_A_TIMEOUT, that is a
completely separate issue. If you want to fix that, we can for sure
use a card quirk - although that quirk should only override the sleep
timeout value that we use in the kernel - and not prevent the sleep
command.
>
> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> ---
> Changes in v2:
> - New patch. v1 used a card-level MMC_QUIRK_BROKEN_SLEEP quirk
> instead of a DT property; this documents the DT property backing
> the host capability added in patch 2, per Ulf's suggestion.
> - Reworded the rationale in the commit message and the binding
> description per Florian's review.
>
> .../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> index 3d7195e9461c..11df0524530c 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> @@ -232,6 +232,14 @@ properties:
> description:
> All eMMC HS400 modes are not supported.
>
> + no-mmc-sleep:
This is a misleading name, please try to find a better one.
The property should say "because of FW, we need to keep power in
suspend but re-initialize it at resume".
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + The attached (e)MMC card cannot reliably resume from the SLEEP
> + (CMD5) state within its advertised S_A_TIMEOUT, so the
> + controller must not put it to sleep during suspend or power
> + off.
> +
Please rephrase this, along the lines of what I suggested above.
> dsr:
> description:
> Value the card Driver Stage Register (DSR) should be programmed
> --
> 2.34.1
>
Kind regards
Uffe
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2 2/2] mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability
2026-07-17 18:05 [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume Kamal Dasu
2026-07-17 18:05 ` [PATCH v2 1/2] dt-bindings: mmc: Document no-mmc-sleep property Kamal Dasu
@ 2026-07-17 18:05 ` Kamal Dasu
2026-07-18 13:51 ` Ulf Hansson
2026-07-18 13:32 ` [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume Ulf Hansson
2 siblings, 1 reply; 6+ messages in thread
From: Kamal Dasu @ 2026-07-17 18:05 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
Some (e)MMC devices take longer to exit the SLEEP (CMD5) state than
their advertised S_A_TIMEOUT allows for. On platforms where a boot
ROM sends CMD0 and reads boot code from the card immediately on
resume, a card still asleep at that point causes the ROM to treat
it as fatal and reset.
Add MMC_CAP2_NO_SLEEP_CMD, settable via the new "no-mmc-sleep" DT
property, so affected hosts can tell mmc_card_can_sleep() to never
put the card to sleep, regardless of ext_csd revision. This is a
host-level capability rather than a card quirk so it also covers
cards whose bug can't be identified by CID/ext_csd matching alone,
and it is resolved before the card even exists, avoiding any
ordering dependency on when a card-quirk table would be applied.
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 v2:
- Replaced the card-level MMC_QUIRK_BROKEN_SLEEP quirk (keyed off
CID) with a host capability, MMC_CAP2_NO_SLEEP_CMD, set from the
new "no-mmc-sleep" DT property, per Ulf's suggestion that this
generalize beyond one device's CID.
- Resolving the capability in mmc_of_parse(), before any card
exists, also addresses Oleksij's concern that a quirk registered
in mmc_blk_fixups[] (applied at mmc_block probe time) could lose
a race against an earlier SLEEP/poweroff on an under-voltage
path.
- Added Reported-by/Closes tags crediting Florian for the original
bug report.
drivers/mmc/core/host.c | 2 ++
drivers/mmc/core/mmc.c | 3 +++
include/linux/mmc/host.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index b7ce3137d452..3bc19645ea96 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-sleep"))
+ host->caps2 |= MMC_CAP2_NO_SLEEP_CMD;
/* 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..5e80fa5c1a28 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1972,6 +1972,9 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
static bool mmc_card_can_sleep(struct mmc_card *card)
{
+ if (card->host->caps2 & MMC_CAP2_NO_SLEEP_CMD)
+ return false;
+
return card->ext_csd.rev >= 3;
}
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba84f02c2a10..0447a8efed50 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_SLEEP_CMD (1 << 29) /* Card can't reliably wake from CMD5 SLEEP */
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] 6+ messages in thread* Re: [PATCH v2 2/2] mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability
2026-07-17 18:05 ` [PATCH v2 2/2] mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability Kamal Dasu
@ 2026-07-18 13:51 ` Ulf Hansson
0 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2026-07-18 13:51 UTC (permalink / raw)
To: Kamal Dasu
Cc: Ulf Hansson, 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 Fri, Jul 17, 2026 at 8:06 PM Kamal Dasu <kamal.dasu@broadcom.com> wrote:
>
> Some (e)MMC devices take longer to exit the SLEEP (CMD5) state than
> their advertised S_A_TIMEOUT allows for. On platforms where a boot
> ROM sends CMD0 and reads boot code from the card immediately on
> resume, a card still asleep at that point causes the ROM to treat
> it as fatal and reset.
>
> Add MMC_CAP2_NO_SLEEP_CMD, settable via the new "no-mmc-sleep" DT
> property, so affected hosts can tell mmc_card_can_sleep() to never
> put the card to sleep, regardless of ext_csd revision. This is a
> host-level capability rather than a card quirk so it also covers
> cards whose bug can't be identified by CID/ext_csd matching alone,
> and it is resolved before the card even exists, avoiding any
> ordering dependency on when a card-quirk table would be applied.
>
> 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 v2:
> - Replaced the card-level MMC_QUIRK_BROKEN_SLEEP quirk (keyed off
> CID) with a host capability, MMC_CAP2_NO_SLEEP_CMD, set from the
> new "no-mmc-sleep" DT property, per Ulf's suggestion that this
> generalize beyond one device's CID.
> - Resolving the capability in mmc_of_parse(), before any card
> exists, also addresses Oleksij's concern that a quirk registered
> in mmc_blk_fixups[] (applied at mmc_block probe time) could lose
> a race against an earlier SLEEP/poweroff on an under-voltage
> path.
> - Added Reported-by/Closes tags crediting Florian for the original
> bug report.
>
> drivers/mmc/core/host.c | 2 ++
> drivers/mmc/core/mmc.c | 3 +++
> include/linux/mmc/host.h | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index b7ce3137d452..3bc19645ea96 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-sleep"))
> + host->caps2 |= MMC_CAP2_NO_SLEEP_CMD;
>
> /* 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..5e80fa5c1a28 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1972,6 +1972,9 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>
> static bool mmc_card_can_sleep(struct mmc_card *card)
> {
> + if (card->host->caps2 & MMC_CAP2_NO_SLEEP_CMD)
> + return false;
> +
No.
As I said several times by now, we should not just skip the sleep
command, but rather always keep the card powered on.
So, instead I suggest we look at adjusting the code in _mmc_suspend()
to cope with this.
> return card->ext_csd.rev >= 3;
> }
>
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index ba84f02c2a10..0447a8efed50 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_SLEEP_CMD (1 << 29) /* Card can't reliably wake from CMD5 SLEEP */
>
> bool uhs2_sd_tran; /* UHS-II flag for SD_TRAN state */
> bool uhs2_app_cmd; /* UHS-II flag for APP command */
> --
> 2.34.1
>
Kind regards
Uffe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume
2026-07-17 18:05 [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume Kamal Dasu
2026-07-17 18:05 ` [PATCH v2 1/2] dt-bindings: mmc: Document no-mmc-sleep property Kamal Dasu
2026-07-17 18:05 ` [PATCH v2 2/2] mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability Kamal Dasu
@ 2026-07-18 13:32 ` Ulf Hansson
2 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2026-07-18 13:32 UTC (permalink / raw)
To: Kamal Dasu
Cc: Ulf Hansson, 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 Fri, Jul 17, 2026 at 8:06 PM Kamal Dasu <kamal.dasu@broadcom.com> wrote:
>
> This is v2 of Florian's original patch:
>
> Link: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli@broadcom.com/
>
> Background: the Kioxia 016G01 eMMC takes ~10ms to exit SLEEP (CMD5)
> instead of the ~1ms it advertises via S_A_TIMEOUT, which can be
> problematic on systems that resume from Suspend-to-DRAM by first
> pulling boot code from eMMC using hard wired logic that is not field
> updatable -- if the card is still asleep when that logic reads it, it
> resets the board. The device stays powered throughout suspend-to-
> DRAM (no software-controlled VCC/VCCQ regulator toggling on this
> path), and the CMD0-before-resume sequence follows the JEDEC boot
> spec, so this isn't something the kernel's resume ordering can fix
> on its own.
>
> v1 addressed this with a card-level MMC_QUIRK_BROKEN_SLEEP quirk
> keyed off the device CID. Ulf pointed out that a device-specific
> quirk doesn't generalize well and suggested a host capability bit
> instead, settable from DT (or derived from a compatible string),
> mirroring the existing no-sdio/no-sd/no-mmc properties. Oleksij
> separately noted that quirks registered in mmc_blk_fixups[] are only
> applied once the mmc_block driver probes, which is too late to avoid
> a race against an earlier SLEEP/poweroff triggered on an under-
> voltage path -- a host cap resolved in mmc_of_parse(), before any
> card exists, sidesteps that ordering problem entirely.
>
> This series implements that direction:
>
> - Patch 1 documents a new "no-mmc-sleep" DT flag property.
> - Patch 2 adds MMC_CAP2_NO_SLEEP_CMD, parses the DT property in
> mmc_of_parse(), and has mmc_card_can_sleep() honor it.
Hmm, this sounds like this is about skipping the sleep command, while
in fact what is needed is to keep the eMMC card powered on during
system suspend [1].
Moreover, during system resume, even if the card remains powered on,
the kernel still needs to do a re-initialization of the card, because
the FW has already used the eMMC before the kernel resumes.
If you could rephrase the description in the cover letter and its
header towards this, I would appreciate it as it would become more
clear what we need here.
>
> The actual board DT change (adding "no-mmc-sleep;" to the affected
> brcmstb eMMC controller node) will follow separately once this lands,
> since that DT lives outside of mainline.
>
> Changes in v2:
> - Dropped the card-quirk/CID-match approach entirely in favor of a
> host capability bit, per Ulf's suggestion.
> - Added a DT property ("no-mmc-sleep") to set that capability,
> following the no-sdio/no-sd/no-mmc precedent, per Ulf.
> - This also resolves Oleksij's concern about mmc_blk_fixups[]
> being applied too late to close the race on an early
> SLEEP/poweroff path, since the host cap is resolved in
> mmc_of_parse() before a card exists.
> - Reworded the rationale in patch 1's commit message and binding
> description per Florian's review.
> - Added a Reported-by/Closes tag crediting Florian for the
> original bug report.
>
> Kamal Dasu (2):
> dt-bindings: mmc: Document no-mmc-sleep property
> mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability
>
> .../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
> drivers/mmc/core/host.c | 2 ++
> drivers/mmc/core/mmc.c | 3 +++
> include/linux/mmc/host.h | 1 +
> 4 files changed, 14 insertions(+)
>
> --
> 2.34.1
>
Kind regards
Uffe
[1]
https://lore.kernel.org/all/CAPx+jO-RJYCwKLLYCPZw8nR0VLVJ+UXPotXwXXRHGvar04QyDg@mail.gmail.com/
^ permalink raw reply [flat|nested] 6+ messages in thread