Re: [PATCH v3 1/2] dt-bindings: mmc: Document no-mmc-poweroff-suspend property
Krzysztof Kozlowski <[email protected]> Thu, 23 Jul 2026 09:51:49 +0200
| Newsgroups | org.kernel.vger.linux-mmc,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260723-venerable-infallible-oriole-434b75@quoll> |
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? Best regards, Krzysztof