[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHp75VcGTgd6T4p-5ceE61Y3CGQ4qriXh=VV3kBi=hEF9hNPWw@mail.gmail.com>
Date: Tue, 13 Jan 2026 23:13:51 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Gideon Adjei <gideonadjei.dev@...il.com>
Cc: Andy Shevchenko <andy@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Abdun Nihaal <abdun.nihaal@...il.com>, Dan Carpenter <dan.carpenter@...aro.org>,
Jianglei Nie <niejianglei2021@....com>, Matthew Wilcox <willy@...radead.org>,
dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] staging: fbtft: Change udelay() to usleep_range()
On Tue, Jan 13, 2026 at 11:06 PM Gideon Adjei <gideonadjei.dev@...il.com> wrote:
>
> Replace udelay() calls >= 100us with usleep_range() to avoid busy-waiting.
>
> The delays are used in init_display() callbacks. These callbacks are
> invoked by fbtft_probe_common() during the driver's probe path. the
> probe path runs in process context which already uses sleeping APIs.
> This makes usleep_range() safe to use in these situations.
Nice, now can we switch to modern API, i.e. fsleep()?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists