Re: [PATCH v3 1/2] dt-bindings: mmc: Document no-mmc-poweroff-suspend property

On Thu, Jul 23, 2026 at 3:51 AM Krzysztof Kozlowski <[email protected]> wrote:

> On Wed, Jul 22, 2026 at 05:14:16PM -0400, Kamal Dasu wrote:
> > 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 <[email protected]>
> > ---
> > 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.
>
> Isn't this exactly the same as keep-power-in-suspend?
>
>
Not quite, though I see why it reads that way from the description
alone.

keep-power-in-suspend only takes effect through host->pm_flags, which
gets set at runtime via sdio_set_host_pm_flags() -- an SDIO function
driver opts in from its own suspend() callback, per suspend cycle.
The consuming logic lives entirely in mmc_sdio_suspend()/
mmc_sdio_resume() (drivers/mmc/core/sdio.c); pm_flags is never read
in mmc.c, which is what this series touches.

no-mmc-poweroff-suspend differs in two ways:

  - It's a fixed platform characteristic, not a per-driver runtime
    request. There's no SDIO-style function driver to call an opt-in
    API from for a plain (e)MMC storage card -- the requirement here
    (firmware always touches the card at resume, on this board) is
    always true, not something decided per suspend cycle.
  - The resume-side behavior differs. keep-power-in-suspend without a
    wake IRQ does nothing at resume: it assumes the card's state
    survived untouched. This flag needs the opposite -- keep power,
    but still fully re-initialize the card via mmc_init_card(), since
    firmware may have reconfigured it while the kernel was suspended.

Given those differences I went with a host capability following the
existing no-sdio/no-sd/no-mmc/no-mmc-hs400 pattern in mmc_of_parse()
rather than extending pm_flags/keep-power-in-suspend, but happy to
hear if you see a cleaner way to fold this in.

Kamal


>
> Best regards,
> Krzysztof
>
>