Replace udelay(100) calls with usleep_range(100, 200) to allow the
scheduler to yield instead of busy-waiting. This is the preferred API for
sleep durations above 10 microseconds.

Signed-off-by: Olle Lukowski <olle@lukowski.dev>
---
This patch replaces udelay() with usleep_range() in fb_ra8875.
---
 drivers/staging/fbtft/fb_ra8875.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de664..d2400bb44 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -210,7 +210,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
 	}
 	len--;
 
-	udelay(100);
+	usleep_range(100, 200);
 
 	if (len) {
 		buf = (u8 *)par->buf;
@@ -231,7 +231,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
 
 	/* restore user spi-speed */
 	par->fbtftops.write = fbtft_write_spi;
-	udelay(100);
+	usleep_range(100, 200);
 }
 
 static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)

---
base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada
change-id: 20251020-staging-fbtft-ra8875-usleep-77306ea543c7

Best regards,
-- 
Olle Lukowski <olle@lukowski.dev>

On Mon, Oct 20, 2025 at 10:16 PM Olle Lukowski <olle@lukowski.dev> wrote:
>
> Replace udelay(100) calls with usleep_range(100, 200) to allow the
> scheduler to yield instead of busy-waiting. This is the preferred API for
> sleep durations above 10 microseconds.

...

> -       udelay(100);
> +       usleep_range(100, 200);

Besides what Greg said, the function in similar changes should be
fsleep(), it will automatically choose the best low-level API for the
given delay.

-- 
With Best Regards,
Andy Shevchenko

On Mon, Oct 20, 2025 at 10:15:36PM +0300, Olle Lukowski wrote:
> Replace udelay(100) calls with usleep_range(100, 200) to allow the
> scheduler to yield instead of busy-waiting. This is the preferred API for
> sleep durations above 10 microseconds.

As per this type of change, have you tested it on real hardware?
Without that, we can't accept this change, and such checkpatch.pl
comments should be ignored.

thanks,

greg k-h

Hi Greg,

On Tue, Oct 21, 2025 at 09:37:50AM +0200, Greg Kroah-Hartman wrote:
> As per this type of change, have you tested it on real hardware?
> Without that, we can't accept this change, and such checkpatch.pl
> comments should be ignored.

Thanks for clarifying!

I don't have access to the hardware for this driver, so I'll skip these
types of timing-related changes for now and focus on other
non-functional cleanups in staging instead.

Thanks again,
Olle