All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Judith Mendez" <jm@ti.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 3/3] mmc: core: Add power-off-delay-us support
Date: Wed, 22 Jul 2026 21:06:45 +0000	[thread overview]
Message-ID: <20260722210645.D9E561F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260722205701.372789-4-jm@ti.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Replacing `mmc_delay(1)` with `mmc_delay_us(host->ios.power_off_delay_us)` (which defaults to 1000) inadvertently changes the underlying timer mechanism from `usleep_range` to `msleep(1)`, introducing a latency regression of up to ~20ms per power-off cycle.
--

--- Patch [3]: [PATCH v2 3/3] mmc: core: Add power-off-delay-us support ---
commit 028a9284e6d11b892584840a7f05aeed49d66b60
Author: Judith Mendez <jm@ti.com>

mmc: core: Add power-off-delay-us support

This commit adds support for power-off-delay-us to specify a custom delay
after deasserting power during MMC power cycles. The default delay is set
to 1000us, but can be overridden to work around hardware issues.

> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1388,7 +1388,7 @@ void mmc_power_off(struct mmc_host *host)
>  	 * XO-1.5, require a short delay after poweroff before the card
>  	 * can be successfully turned on again.
>  	 */
> -	mmc_delay(1);
> +	mmc_delay_us(host->ios.power_off_delay_us);

[Severity: Medium]
Does this change introduce a latency regression during power management
operations?

The default value for power_off_delay_us is 1000. When mmc_delay_us() is
called with 1000 or greater, it falls into the msleep() path:

drivers/mmc/core/core.h:mmc_delay_us() {
	if (us < 1000) {
		usleep_range(us, us + (us >> 2));
	} else {
		unsigned int rem_us = us % 1000;

		msleep(us / 1000);
		if (rem_us)
			usleep_range(rem_us, rem_us + (rem_us >> 2));
	}
}

This effectively calls msleep(1), which uses jiffy-based timeouts. On
systems where HZ=100, this can delay execution by up to 20ms per power-off
cycle. The original mmc_delay(1) call correctly used the high-resolution
usleep_range(1000, 1250) timer mechanism.

Could the threshold for mmc_delay_us() be adjusted, or could usleep_range()
be used to avoid an unintended jiffy-based sleep?

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

      reply	other threads:[~2026-07-22 21:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 20:56 [PATCH v2 0/3] mmc: Add power_off_delay_us support Judith Mendez
2026-07-22 20:56 ` [PATCH v2 1/3] dt-bindings: mmc: Add power-off-delay-us property Judith Mendez
2026-07-22 20:57 ` [PATCH v2 2/3] mmc: core: Add mmc_delay_us() for microsecond precision delays Judith Mendez
2026-07-22 21:04   ` sashiko-bot
2026-07-22 20:57 ` [PATCH v2 3/3] mmc: core: Add power-off-delay-us support Judith Mendez
2026-07-22 21:06   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260722210645.D9E561F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jm@ti.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.