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

Hi Ulf,

On 7/17/26 5:21 AM, Ulf Hansson wrote:
> On Fri, Jul 17, 2026 at 1:26 AM Judith Mendez <[email protected]> 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 <[email protected]>
>> ---
>>   .../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