[PATCH 0/2] mmc: Add post-power-off-delay-ms support

[PATCH 0/2] mmc: Add post-power-off-delay-ms support

[Judith Mendez]

This series adds post-power-off-delay-ms support for MMC controllers,
enabling boards to specify custom delays after MMC power off to work around
hardware issues such as slow RC circuites on MMC VDD rails.

Rather than adding host driver-specific workarounds, we abstract the
implementation into the MMC core and pickup the delay value with a device
tree property (post-power-off-delay-ms). This allows any board with slow
power off requirements to configure the necessary delay without code
changes.

Requesting comments for how big the delay should be maxed at, currently
it is set to 10000ms, but not sure if this is too high.

The solution is minimal and follows existing patterns as with
(post-power-on-delay-ms).

Judith Mendez (2):
  dt-bindings: mmc: Add post-power-off-delay-ms property
  mmc: core: Add post-power-off-delay-ms support

 .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
 drivers/mmc/core/core.c                                   | 8 ++++++--
 drivers/mmc/core/host.c                                   | 8 ++++++++
 include/linux/mmc/host.h                                  | 1 +
 4 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.54.0

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

[Judith Mendez]

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.

Signed-off-by: Judith Mendez <jm@ti.com>
---
 .../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:
+    description:
+      The presence of this property indicates that the card requires a
+      delay (in milliseconds) after power off before the next power on.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 10000
+
   supports-cqe:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.54.0

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

[Rob Herring (Arm)]

On Thu, 16 Jul 2026 18:26:40 -0500, Judith Mendez 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.
> 
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>  .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml: properties:post-power-off-delay-ms: '$ref' should not be valid under {'const': '$ref'}
	hint: Standard unit suffix properties don't need a type $ref
	from schema $id: http://devicetree.org/meta-schemas/core.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260716232641.2659710-2-jm@ti.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

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

[Ulf Hansson]

On Fri, Jul 17, 2026 at 1:26 AM Judith Mendez <jm@ti.com> 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@ti.com>
> ---
>  .../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.

> +    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

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@ti.com> 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@ti.com>
>> ---
>>   .../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

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

[Judith Mendez]

Hi Ulf,

On 7/17/26 12:40 PM, Judith Mendez wrote:
> Hi Ulf,
> 
> On 7/17/26 5:21 AM, Ulf Hansson wrote:
>> On Fri, Jul 17, 2026 at 1:26 AM Judith Mendez <jm@ti.com> 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@ti.com>
>>> ---
>>>   .../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.
> 

Forgot to mention, we are using mmc_delay which takes ms, if we switch
to microsecond dt property, we would have to make conversions or not use
mmc_delay.

~ Judith

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@ti.com> 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@ti.com>
>> ---
>>   .../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.
> 
>> +    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 would like to keep the limits from minimum 1ms to 10000ms just because
likely someone will go ahead and add a huge delay and wonder why their
board just crashed. I think 10000ms or 10s is large enough, what do you
think?

...

[PATCH 2/2] mmc: core: Add post-power-off-delay-ms support

[Judith Mendez]

Add support for post-power-off-delay-ms which shall be used to insert
a configurable delay post MMC power off.

Signed-off-by: Judith Mendez <jm@ti.com>
---
 drivers/mmc/core/core.c  | 8 ++++++--
 drivers/mmc/core/host.c  | 8 ++++++++
 include/linux/mmc/host.h | 1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 29e80e5f928e9..f9049aaf44394 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1394,8 +1394,12 @@ void mmc_power_off(struct mmc_host *host)
 void mmc_power_cycle(struct mmc_host *host, u32 ocr)
 {
 	mmc_power_off(host);
-	/* Wait at least 1 ms according to SD spec */
-	mmc_delay(1);
+	if (host->post_power_off_delay_ms) {
+		mmc_delay(host->post_power_off_delay_ms);
+	} else {
+		/* Wait at least 1 ms according to SD spec */
+		mmc_delay(1);
+	}
 	mmc_power_up(host, ocr);
 }
 
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index b7ce3137d4529..ea8f36827e41c 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -421,6 +421,14 @@ int mmc_of_parse(struct mmc_host *host)
 	device_property_read_u32(dev, "post-power-on-delay-ms",
 				 &host->ios.power_delay_ms);
 
+	device_property_read_u32(dev, "post-power-off-delay-ms",
+				 &host->post_power_off_delay_ms);
+	if (host->post_power_off_delay_ms > 10000) {
+		dev_err(dev, "post-power-off-delay-ms %u exceeds max 10000, setting 10000\n",
+			host->post_power_off_delay_ms);
+		host->post_power_off_delay_ms = 10000;
+	}
+
 	return mmc_pwrseq_alloc(host);
 }
 
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba84f02c2a101..b751b61b1116e 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -578,6 +578,7 @@ struct mmc_host {
 
 	u32			err_stats[MMC_ERR_MAX];
 	u32			max_sd_hs_hz;
+	u32			post_power_off_delay_ms;
 	unsigned long		private[] ____cacheline_aligned;
 };
 
-- 
2.54.0

Re: [PATCH 2/2] mmc: core: Add post-power-off-delay-ms support

[Ulf Hansson]

On Fri, Jul 17, 2026 at 1:26 AM Judith Mendez <jm@ti.com> wrote:
>
> Add support for post-power-off-delay-ms which shall be used to insert
> a configurable delay post MMC power off.
>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>  drivers/mmc/core/core.c  | 8 ++++++--
>  drivers/mmc/core/host.c  | 8 ++++++++
>  include/linux/mmc/host.h | 1 +
>  3 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 29e80e5f928e9..f9049aaf44394 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1394,8 +1394,12 @@ void mmc_power_off(struct mmc_host *host)
>  void mmc_power_cycle(struct mmc_host *host, u32 ocr)
>  {
>         mmc_power_off(host);
> -       /* Wait at least 1 ms according to SD spec */
> -       mmc_delay(1);

The above delay is kind of questionable in the first place, as we
already have a mmc_delay(1) at the end of mmc_power_off().

Maybe the delay is needed for legacy reasons and because of that, I
would suggest that we leave mmc_power_cycle() as is, for now. In the
end, I would rather see that the above delay gets removed altogether.

Instead, how about making the mmc_delay(1) in mmc_power_off() configurable?

Moreover, rather than the code below, I think it would be better to
set a default value for "host->post_power_off_delay_ms" to 1 in
mmc_alloc_host(). In fact, there is already similar code for
"host->ios.power_delay_ms", please try to follow that for this case
too.

> +       if (host->post_power_off_delay_ms) {
> +               mmc_delay(host->post_power_off_delay_ms);
> +       } else {
> +               /* Wait at least 1 ms according to SD spec */
> +               mmc_delay(1);
> +       }
>         mmc_power_up(host, ocr);
>  }
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index b7ce3137d4529..ea8f36827e41c 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -421,6 +421,14 @@ int mmc_of_parse(struct mmc_host *host)
>         device_property_read_u32(dev, "post-power-on-delay-ms",
>                                  &host->ios.power_delay_ms);
>
> +       device_property_read_u32(dev, "post-power-off-delay-ms",
> +                                &host->post_power_off_delay_ms);
> +       if (host->post_power_off_delay_ms > 10000) {
> +               dev_err(dev, "post-power-off-delay-ms %u exceeds max 10000, setting 10000\n",
> +                       host->post_power_off_delay_ms);
> +               host->post_power_off_delay_ms = 10000;
> +       }
> +
>         return mmc_pwrseq_alloc(host);
>  }
>
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index ba84f02c2a101..b751b61b1116e 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -578,6 +578,7 @@ struct mmc_host {
>
>         u32                     err_stats[MMC_ERR_MAX];
>         u32                     max_sd_hs_hz;
> +       u32                     post_power_off_delay_ms;
>         unsigned long           private[] ____cacheline_aligned;
>  };
>
> --
> 2.54.0
>

Kind regards
Uffe