From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "FUJITA Tomonori" <fujita.tomonori@gmail.com>,
<a.hindborg@kernel.org>, <alex.gaynor@gmail.com>,
<ojeda@kernel.org>
Cc: <aliceryhl@google.com>, <anna-maria@linutronix.de>,
<bjorn3_gh@protonmail.com>, <boqun.feng@gmail.com>,
<dakr@kernel.org>, <frederic@kernel.org>, <gary@garyguo.net>,
<jstultz@google.com>, <linux-kernel@vger.kernel.org>,
<lossin@kernel.org>, <lyude@redhat.com>,
<rust-for-linux@vger.kernel.org>, <sboyd@kernel.org>,
<tglx@linutronix.de>, <tmgross@umich.edu>,
<daniel.almeida@collabora.com>, "Fiona Behrens" <me@kloenk.dev>
Subject: Re: [PATCH v2 2/2] rust: Add read_poll_timeout functions
Date: Tue, 19 Aug 2025 09:49:38 +0900 [thread overview]
Message-ID: <DC5ZPDQADDJT.32SFK2OHDRGTG@nvidia.com> (raw)
In-Reply-To: <20250817044724.3528968-3-fujita.tomonori@gmail.com>
On Sun Aug 17, 2025 at 1:47 PM JST, FUJITA Tomonori wrote:
> Add read_poll_timeout function which poll periodically until a
> condition is met or a timeout is reached.
>
> The C's read_poll_timeout (include/linux/iopoll.h) is a complicated
> macro and a simple wrapper for Rust doesn't work. So this implements
> the same functionality in Rust.
>
> The C version uses usleep_range() while the Rust version uses
> fsleep(), which uses the best sleep method so it works with spans that
> usleep_range() doesn't work nicely with.
>
> The sleep_before_read argument isn't supported since there is no user
> for now. It's rarely used in the C version.
>
> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Reviewed-by: Fiona Behrens <me@kloenk.dev>
> Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Tested this with nova-core, and it seems to work fine!
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Just one last comment about the documentation below.
<snip>
> +/// Polls periodically until a condition is met or a timeout is reached.
> +///
> +/// The function repeatedly executes the given operation `op` closure and
> +/// checks its result using the condition closure `cond`.
> +///
> +/// If `cond` returns `true`, the function returns successfully with the result of `op`.
> +/// Otherwise, it waits for a duration specified by `sleep_delta`
> +/// before executing `op` again.
> +///
> +/// This process continues until either `cond` returns `true` or the timeout,
> +/// specified by `timeout_delta`, is reached. If `timeout_delta` is `None`,
For precision: "This process continues until either `op` returns and
error, `cond` returns `true`, or the timeout specified by
`timeout_delta` is reached."
> +/// polling continues indefinitely until `cond` evaluates to `true` or an error occurs.
> +///
> +/// This function can only be used in a nonatomic context.
Here I'd add an errors section:
# Errors
If `op` returns an error, then that error is returned directly.
If the timeout specified by `timeout_delta` is reached, then
`Err(ETIMEDOUT)` is returned.
> +///
> +/// # Examples
> +///
> +/// ```no_run
> +/// use kernel::io::{Io, poll::read_poll_timeout};
> +/// use kernel::time::Delta;
> +///
> +/// const HW_READY: u16 = 0x01;
> +///
> +/// fn wait_for_hardware<const SIZE: usize>(io: &Io<SIZE>) -> Result<()> {
> +/// match read_poll_timeout(
> +/// // The `op` closure reads the value of a specific status register.
> +/// || io.try_read16(0x1000),
> +/// // The `cond` closure takes a reference to the value returned by `op`
> +/// // and checks whether the hardware is ready.
> +/// |val: &u16| *val == HW_READY,
> +/// Delta::from_millis(50),
> +/// Delta::from_secs(3),
> +/// ) {
> +/// Ok(_) => {
> +/// // The hardware is ready. The returned value of the `op` closure
> +/// // isn't used.
> +/// Ok(())
> +/// }
> +/// Err(e) => Err(e),
> +/// }
> +/// }
> +/// ```
> +#[track_caller]
> +pub fn read_poll_timeout<Op, Cond, T>(
> + mut op: Op,
> + mut cond: Cond,
> + sleep_delta: Delta,
> + timeout_delta: Delta,
> +) -> Result<T>
> +where
> + Op: FnMut() -> Result<T>,
> + Cond: FnMut(&T) -> bool,
> +{
> + let start: Instant<Monotonic> = Instant::now();
> +
> + // Unlike the C version, we always call `might_sleep()` unconditionally,
> + // as conditional calls are error-prone. We clearly separate
> + // `read_poll_timeout()` and `read_poll_timeout_atomic()` to aid
> + // tools like klint.
> + might_sleep();
> +
> + loop {
> + let val = op()?;
> + if cond(&val) {
> + // Unlike the C version, we immediately return.
> + // We know the condition is met so we don't need to check again.
nit: this comment looks superfluous to me, this is a different
implementation from the C version anyway.
> + return Ok(val);
> + }
> +
> + if start.elapsed() > timeout_delta {
> + // Unlike the C version, we immediately return.
> + // We have just called `op()` so we don't need to call it again.
Same here.
next prev parent reply other threads:[~2025-08-19 0:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-17 4:47 [PATCH v2 0/2] rust: Add read_poll_timeout FUJITA Tomonori
2025-08-17 4:47 ` [PATCH v2 1/2] rust: Add cpu_relax() helper FUJITA Tomonori
2025-08-19 18:32 ` Daniel Almeida
2025-10-02 16:32 ` ChaosEsque Team
2025-10-02 16:33 ` ChaosEsque Team
2025-10-02 16:34 ` ChaosEsque Team
2025-10-02 16:36 ` ChaosEsque Team
2025-08-17 4:47 ` [PATCH v2 2/2] rust: Add read_poll_timeout functions FUJITA Tomonori
2025-08-19 0:49 ` Alexandre Courbot [this message]
2025-08-20 11:11 ` FUJITA Tomonori
2025-08-19 18:30 ` Daniel Almeida
2025-08-20 6:45 ` FUJITA Tomonori
2025-08-20 10:02 ` Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DC5ZPDQADDJT.32SFK2OHDRGTG@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=anna-maria@linutronix.de \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=frederic@kernel.org \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=me@kloenk.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.