[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHp75Vc9fnuMb3s-KtX5r+nmOH5BztP=d+h9FXpn2i34sCv2-Q@mail.gmail.com>
Date: Mon, 29 Dec 2025 09:41:00 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Alexandru Costin <spxxky.dev@...il.com>
Cc: andy@...nel.org, gregkh@...uxfoundation.org,
dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: 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"
On Mon, Dec 29, 2025 at 3:09 AM Alexandru Costin <spxxky.dev@...il.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
Powered by blists - more mailing lists