[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

[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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `post-power-off-delay-ms` hardware constraint is only enforced in `mmc_power_cycle()`, leaving decoupled power-off/power-on sequences vulnerable to hardware timing violations.
- [Low] Explicitly configuring a 0 ms post-power-off delay in the device tree is ignored, falling back to the 1 ms default.
--

--- Patch [2]: [PATCH 2/2] mmc: core: Add post-power-off-delay-ms support ---
commit 36ce7de56b9b7e7608c56353aede4cb3de73df5b
Author: Judith Mendez <jm@ti.com>

mmc: core: Add post-power-off-delay-ms support

This commit adds support for post-power-off-delay-ms, allowing a
configurable delay after an MMC power off.

> 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);
> +	}

[Severity: Medium]
Will this delay be missed for decoupled power-off and power-on sequences?

If a device relies on post-power-off-delay-ms (e.g., 100ms) but goes through a
runtime PM suspend or system suspend, mmc_power_off() will be called, followed
later by mmc_power_up(). Because the delay is only enforced here in
mmc_power_cycle(), will the decoupled off/on path violate the power-off time
constraint?

Could mmc_power_off() record a timestamp, and mmc_power_up() calculate the
elapsed time to only delay the remaining required duration?

[Severity: Low]
Does this ignore an explicitly configured 0 ms delay?

If a developer explicitly specifies post-power-off-delay-ms = <0> in the
device tree, this condition will evaluate to false and unexpectedly fall
back to the 1 ms default.

Could this be resolved by initializing the default value in mmc_alloc_host()
and removing the if/else condition here?

>  	mmc_power_up(host, ocr);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716232641.2659710-1-jm@ti.com?part=2