Re: [PATCH v5 1/2] dt-bindings: mmc: Extend keep-power-in-suspend beyond SDIO

On Wed, Jul 29, 2026 at 10:14=E2=80=AFPM Kamal Dasu <[email protected]=
m> wrote:
>
> keep-power-in-suspend already documents exactly the requirement
> needed on (e)MMC platforms where firmware accesses the card directly
> during resume. Rather than add a separate property describing the
> same contract, drop its "SDIO only" restriction and document the
> (e)MMC use case alongside the existing SDIO one.
>
> Signed-off-by: Kamal Dasu <[email protected]>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
> ---
> Changes in v5:
>   - Added Krzysztof's Reviewed-by.
>
> Changes in v4:
>   - Dropped no-mmc-poweroff-suspend entirely and extended
>     keep-power-in-suspend instead, per Krzysztof: the two properties
>     described the same "don't power off across suspend/resume"
>     contract.
>
> 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.
>
>  Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml | 7 +++=
+++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.=
yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> index 3d7195e9461c..f4663b318435 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> @@ -291,7 +291,12 @@ properties:
>    keep-power-in-suspend:
>      $ref: /schemas/types.yaml#/definitions/flag
>      description:
> -      SDIO only. Preserves card power during a suspend/resume cycle.
> +      Preserves card power during a suspend/resume cycle. For SDIO,
> +      this is a request an individual function driver can make at
> +      runtime via sdio_set_host_pm_flags(). For (e)MMC, it is instead
> +      a fixed platform characteristic, needed on boards where firmware
> +      accesses the card directly during system resume, before the
> +      kernel's own resume path runs.

I realized that I responded to an earlier version yesterday, anyway
the comment for v4 applies to v5 as well. So in a new version, please
rephrase the descriptions to mention HW/FW and not software.

Moreover, as I said at v3, I don't think re-using
"keep-power-in-suspend" is sufficient to cover the brcmstb boards.

"keep-power-in-suspend" means that the power for the card must be
preserved during suspend/resume, yet at the moment this is limited to
SDIO cards. I made some more thinking and below is my suggestion for
how to move forward.

To be able to describe the brcmstb boards, I suggest we start by
extending the DT property "keep-power-in-suspend" beyond SDIO, so it
can be used for any type of card (eMMC/SD/SDIO). This should be a
separate patch and the first in the series.

On top, I think we need a new DT property, perhaps something along the
lines of "reset-card-at-resume". In principle, its description should
say "The HW/FW may have accessed the card during suspend/resume,
leaving it in an unknown state. Hence, before the card can be used, it
must be reset."

For the brcmstb boards, we would then need to set both
"keep-power-in-suspend" and "reset-card-at-resume".

Krzysztof, Kamal, does that make sense to you?

>
>    wakeup-source:
>      $ref: /schemas/types.yaml#/definitions/flag
> --
> 2.34.1
>

Kind regards
Uffe