Re: [PATCH] staging: rtl8723bs: replace msleep with usleep_range

[Ofek Almog]

(Resending as plain text, apologies if you received a previous HTML version)

Hi Andy, Ethan,

Thank you both for the review.

Regarding the fsleep() suggestion - understood, that clearly seems
like the right helper to use here.

Regarding the completion mechanism logic - I completely agree that the
current infinite loop polling is fragile. However, as this is my very
first contribution and I do not have the hardware to verify logic
changes, I am hesitant to refactor the synchronization mechanism
blindly.

Would you prefer I send a v2 that strictly switches to fsleep() as an
incremental improvement over msleep(), or should I drop this patch
altogether until someone with the hardware can refactor the logic
properly?

Best regards,
Ofek

‫בתאריך שבת, 14 בפבר׳ 2026 ב-20:24 מאת ‪Andy Shevchenko‬‏
<‪andriy.shevchenko@xxxxxxxxx‬‏>:‬
>
> On Sat, Feb 14, 2026 at 12:11:16PM -0600, Ethan Tidmore wrote:
> > On Sat Feb 14, 2026 at 11:31 AM CST, Ofek Almog wrote:
> > > This patch replaces msleep(10) with usleep_range(10000, 11000) to provide
> > > more precise delay handling while allowing the timer subsystem to coalesce
> > > timers efficiently.
>
> ...
>
> > >     while (pevtpriv->c2h_wk_alive)
> > > -           msleep(10);
> > > +           usleep_range(10000, 11000);
>
> The whole approach here seems to be fragile. It should rather use completion
> mechanism instead of infinite loop.
>
> > >     while (!rtw_cbuf_empty(pevtpriv->c2h_queue)) {
> > >             void *c2h = rtw_cbuf_pop(pevtpriv->c2h_queue);
> >
> > Shouldn't we be using fsleep() now instead of replacing msleep() with
> > usleep_range() when the time is sub 20ms?
> >
> > I feel like I read Andy Shevchenko mention this elsewhere.
>
> Yep.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>