[PATCH] Replace udelay() with usleep_range() in PLL initialization code. According to Documentation/timers/timers-howto.rst, usleep_range() is preferred for delays "10us - 20ms"

[PATCH] Replace udelay() with usleep_range() in PLL initialization code. According to Documentation/timers/timers-howto.rst, usleep_range() is preferred for delays "10us - 20ms"

[Alexandru Costin]

Resolves checkpatch warnings:
  WARNING: usleep_range is preferred over udelay

Signed-off-by: Alexandru Costin <spxxky.dev@gmail.com>
---
 drivers/staging/fbtft/fb_ra8875.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de6647d0..130150b0f07f 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -210,7 +210,8 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
 	}
 	len--;
 
-	udelay(100);
+	usleep_range(100, 120);
+
 
 	if (len) {
 		buf = (u8 *)par->buf;
@@ -231,7 +232,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, 120);
 }
 
 static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
-- 
2.43.0

Re: [PATCH] Replace udelay() with usleep_range() in PLL initialization code. According to Documentation/timers/timers-howto.rst, usleep_range() is preferred for delays "10us - 20ms"

[Andy Shevchenko]

On Mon, Dec 29, 2025 at 3:09 AM Alexandru Costin <spxxky.dev@gmail.com> wrote:
>
> Resolves checkpatch warnings:
>   WARNING: usleep_range is preferred over udelay

First of all, fix checkpatch to point to a newer API, i.e. fsleep().

...

> @@ -210,7 +210,8 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)

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

> @@ -231,7 +232,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)

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

This is an IO function for the hardware in question. Have you tested
it? How do you know that this is a non-atomic context?

-- 
With Best Regards,
Andy Shevchenko