Re: [PATCH v2] iopoll: use udelay() for initial polling

From: Mark Brown

Date: Fri May 22 2026 - 10:56:44 EST


On Thu, May 21, 2026 at 10:03:28AM +0300, Jani Nikula wrote:
> On Wed, 20 May 2026, Peter Collingbourne <peter@xxxxxxxxx> wrote:

> > That's what I had in v1; we decided this approach would better handle
> > misbehaving devices.
> > https://lore.kernel.org/all/20260517150253.031dec09@pumpkin/

> I think the problem with trying to adapt to everything within
> read_poll_timeout() is that every step like this adapts to a *specific*
> use case, and once it gets specific enough, it's no longer usable to
> other scenarios.

> Having to reimplement the whole thing in drivers is much worse than
> having to do two calls.

> Could a staggered approach work?

> ret = read_poll_timeout_atomic("short delay/timeout")
> if (ret)
> ret = read_poll_timeout("longer delay/timeout")

> Then you have better control of the behaviour in the driver, instead of
> adapting a generic function to a specific use case.

If we're doing that it still seems like it'd be better to have a helper
than just takes the two timeouts and does the right thing with them. My
original feedback here was that we should have helpers which encourage
good patterns, and TBH I expect there's probably a bunch of scenarios
where some fixed cutoff would be a worthwile improvement for very little
effort on the part of users.

Attachment: signature.asc
Description: PGP signature