Re: [PATCH 1/2] dt-bindings: mmc: Add post-power-off-delay-ms property

[Judith Mendez]

Hi Ulf,

On 7/17/26 5:21 AM, Ulf Hansson wrote:
> On Fri, Jul 17, 2026 at 1:26 AM Judith Mendez <jm@xxxxxx> wrote:
> > Add post-power-off-delay-ms property to MMC controller common.
> >
> > This property shall be used to specify delay if needed after
> > deasserting power during MMC power cycles.
>
> Please clarify with some additional information from the cover-letter,
> like "specify custom delays after MMC power off to work around
> hardware issues such as slow RC circuites on MMC VDD rails."
>
> > Signed-off-by: Judith Mendez <jm@xxxxxx>
> > ---
> >   .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> > index 3d7195e9461c3..3ff68d32a308f 100644
> > --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> > @@ -275,6 +275,14 @@ properties:
> >         not available.
> >       default: 10
> >
> > +  post-power-off-delay-ms:
>
> For mmc-pwrseq-simple we already have "power-off-delay-us", perhaps
> better to re-use that name instead.

Besides having the same dt property name as mmc-pwrseq-simple what is
the benefit of switching to power-off-delay-us?

All values will have to be in us instead of ms and thus will look a bit
less clean in code. If it is just a naming  preference, I do prefer
the current name in this version, please let me know if we can keep:
post-power-off-delay-ms.

All other comments I agree with and will fix in v2.

Thanks for reviewing (:

~ Judith


> > +    description:
> > +      The presence of this property indicates that the card requires a
> > +      delay (in milliseconds) after power off before the next power on.
>
> Again, maybe something to indicate this is specific like "specify
> custom delays after MMC power off to work around
> hardware issues such as slow RC circuites on MMC VDD rails."
>
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 0
> > +    maximum: 10000
>
> Are the above limits needed at all?
>
> I suggest we add a "default: 1", as that would correspond to the
> hardcoded value that the mmc core currently uses for this delay.
>
> > +
> >     supports-cqe:
> >       $ref: /schemas/types.yaml#/definitions/flag
> >       description:
> > --
> > 2.54.0
>
> Kind regards
> Uffe