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

[Ulf Hansson]

On Thu, Jul 23, 2026 at 9:51 PM Kamal Dasu <kamal.dasu@xxxxxxxxxxxx> wrote:
>
> 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.

Hold on, this isn't what is needed from the HW point of view. At
least, according to what Florian told me from the earlier discussions.

What we need is a property that means: "Keep power in suspend/resume,
but also re-initialize the eMMC/card at resume since the FW have
fiddled with the card before the kernel resumes".

Kind regards
Uffe