Re: [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume

[Ulf Hansson]

On Fri, Jul 17, 2026 at 8:06 PM Kamal Dasu <kamal.dasu@xxxxxxxxxxxx> wrote:
>
> This is v2 of Florian's original patch:
>
>   Link: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli@xxxxxxxxxxxx/
>
> 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@xxxxxxxxxxxxxx/