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

[Kamal Dasu]

On Thu, Jul 23, 2026 at 3:36 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 23/07/2026 21:24, Kamal Dasu wrote:
> > On Thu, Jul 23, 2026 at 3:01 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>
> >> On 23/07/2026 20:53, Kamal Dasu wrote:
> >>> On Thu, Jul 23, 2026 at 3:51 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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 <kamal.dasu@xxxxxxxxxxxx>
> >>>>> ---
> >>>>> 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.
> >>
> >> All this is just driver stuff which I did not ask about.
> >>
> >> The property is described pretty the same - do not power off during
> >> suspend/resume.
> >>
> >
> > Do you want me to fold this change into using 'keep-power-in-suspend'
> > for mmc as well ?.
>
> I don't want a new property if it has exactly the same meaning. Of
> course I am happy to hear why the property has different meaning in
> terms of hardware description. We do not talk here about drivers, obviously.
>

In terms of hardware description, yes, it's the same meaning: don't
power off the card across suspend/resume. I've folded this into
keep-power-in-suspend rather than keeping a separate property --
extended its description to cover (e)MMC alongside the existing SDIO
wording, and reworked the mmc core side to honor it for (e)MMC too.

Sending v4 shortly.


> Best regards,
> Krzysztof

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature