From: Alice Ryhl <aliceryhl@google.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: a.hindborg@kernel.org, alex.gaynor@gmail.com, dakr@kernel.org,
daniel.almeida@collabora.com, ojeda@kernel.org,
anna-maria@linutronix.de, bjorn3_gh@protonmail.com,
boqun.feng@gmail.com, 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
Subject: Re: [PATCH v3 1/2] rust: add udelay() function
Date: Tue, 28 Oct 2025 09:55:35 +0000 [thread overview]
Message-ID: <aQCTFwswY7dDmfbC@google.com> (raw)
In-Reply-To: <20251026125458.2772103-2-fujita.tomonori@gmail.com>
On Sun, Oct 26, 2025 at 09:54:57PM +0900, FUJITA Tomonori wrote:
> Add udelay() function, inserts a delay based on microseconds with busy
> waiting, in preparation for supporting read_poll_timeout_atomic().
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
With below nits addressed:
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> ---
> rust/helpers/time.c | 5 +++++
> rust/kernel/time/delay.rs | 39 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/rust/helpers/time.c b/rust/helpers/time.c
> index a318e9fa4408..67a36ccc3ec4 100644
> --- a/rust/helpers/time.c
> +++ b/rust/helpers/time.c
> @@ -33,3 +33,8 @@ s64 rust_helper_ktime_to_ms(const ktime_t kt)
> {
> return ktime_to_ms(kt);
> }
> +
> +void rust_helper_udelay(unsigned long usec)
> +{
> + udelay(usec);
> +}
> diff --git a/rust/kernel/time/delay.rs b/rust/kernel/time/delay.rs
> index eb8838da62bc..0739b75fb9c3 100644
> --- a/rust/kernel/time/delay.rs
> +++ b/rust/kernel/time/delay.rs
> @@ -47,3 +47,42 @@ pub fn fsleep(delta: Delta) {
> bindings::fsleep(delta.as_micros_ceil() as c_ulong)
> }
> }
> +
> +/// Inserts a delay based on microseconds with busy waiting.
> +///
> +/// Equivalent to the C side [`udelay()`], which delays in microseconds.
> +///
> +/// `delta` must be within `[0, `MAX_UDELAY_MS`]` in milliseconds;
We can nest backticks. This should be:
`[0, MAX_UDELAY_MS]`
> +/// otherwise, it is erroneous behavior. That is, it is considered a bug to
> +/// call this function with an out-of-range value, in which case the function
> +/// will insert a delay for at least the maximum value in the range and
> +/// may warn in the future.
There's a debug assertion now so I would remove the "maxmimu value"
part.
> +/// The behavior above differs from the C side [`udelay()`] for which out-of-range
> +/// values could lead to an overflow and unexpected behavior.
> +///
> +/// [`udelay()`]: https://docs.kernel.org/timers/delay_sleep_functions.html#c.udelay
> +pub fn udelay(delta: Delta) {
> + const MAX_UDELAY_DELTA: Delta = Delta::from_millis(bindings::MAX_UDELAY_MS as i64);
> +
> + debug_assert!(delta.as_nanos() >= 0);
> + debug_assert!(delta <= MAX_UDELAY_DELTA);
> +
> + let delta = if (Delta::ZERO..=MAX_UDELAY_DELTA).contains(&delta) {
> + delta
> + } else {
> + MAX_UDELAY_DELTA
> + };
> +
> + // SAFETY: It is always safe to call `udelay()` with any duration.
> + // Note that the kernel is compiled with `-fno-strict-overflow`
> + // so any out-of-range value could lead to unexpected behavior
> + // but won't lead to undefined behavior.
> + unsafe {
> + // Convert the duration to microseconds and round up to preserve
> + // the guarantee; `udelay()` inserts a delay for at least
> + // the provided duration, but that it may delay for longer
> + // under some circumstances.
> + bindings::udelay(delta.as_micros_ceil() as c_ulong)
> + }
> +}
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-10-28 9:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-26 12:54 [PATCH v3 0/2] Add read_poll_timeout_atomic support FUJITA Tomonori
2025-10-26 12:54 ` [PATCH v3 1/2] rust: add udelay() function FUJITA Tomonori
2025-10-27 9:48 ` Andreas Hindborg
2025-10-28 9:55 ` Alice Ryhl [this message]
2025-10-26 12:54 ` [PATCH v3 2/2] rust: Add read_poll_timeout_atomic function FUJITA Tomonori
2025-10-28 9:56 ` 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=aQCTFwswY7dDmfbC@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.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=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.