Re: [PATCH v2 2/3] mmc: core: Add mmc_delay_us() for microsecond precision delays

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] mmc_delay_us() incorrectly uses msleep() for short delays, causing massive oversleeping and destroying precision
- [Medium] mmc_delay_us() uses usleep_range() with zero slack for small delays and violates timer usage guidelines for <10us delays
--

--- Patch [2]: [PATCH v2 2/3] mmc: core: Add mmc_delay_us() for microsecond precision delays ---
commit c0ce7d5a46919cedbd3c712e3639e844d38294c9
Author: Judith Mendez <jm@ti.com>

mmc: core: Add mmc_delay_us() for microsecond precision delays
    
Add mmc_delay_us() to support microsecond-granularity delays needed
in MMC framework. It uses 25% margin consistent with  mmc_delay() for
timing flexibility.

> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index a028b48be1644..55e9fb3bab9f7 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h

[ ... ]

> @@ -73,6 +73,19 @@ static inline void mmc_delay(unsigned int ms)
>  		msleep(ms);
>  }
>  
> +static inline void mmc_delay_us(unsigned int us)
> +{
> +	if (us < 1000) {
> +		usleep_range(us, us + (us >> 2));

[Severity: Medium]
When us is less than 4, will this pass 0 slack to usleep_range()? For
example, if us is 2, this calls usleep_range(2, 2), which defeats timer
coalescing.

Also, for delays under 10us, should this use udelay() instead? Kernel
documentation recommends udelay() for delays < 10us because the context
switch overhead of usleep_range() often outweighs the delay itself.

> +	} else {
> +		unsigned int rem_us = us % 1000;
> +
> +		msleep(us / 1000);

[Severity: Medium]
Does using msleep() here break the expected microsecond precision?

On systems with a low HZ value (like HZ=100), msleep(1) will sleep for at
least 1 jiffy, which is 10ms. This can cause the function to oversleep by
10-20x the requested duration.

Kernel timers documentation generally recommends using usleep_range() for
delays up to 20ms instead of falling back to msleep() at 1ms.

> +		if (rem_us)
> +			usleep_range(rem_us, rem_us + (rem_us >> 2));

[Severity: Medium]
Similar to the issue above, if rem_us is less than 4, this provides 0 slack
to the hrtimer subsystem.

Additionally, splitting a mixed delay like 1500us into msleep(1) and
usleep_range(500, 625) forces two context switches. Since msleep() has high
variance, does the subsequent fine-grained usleep_range() actually improve
precision, or does it just add unnecessary overhead?

> +	}
> +}
> +
>  void mmc_rescan(struct work_struct *work);

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