All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: dakr@kernel.org, miguel.ojeda.sandonis@gmail.com,
	 daniel.almeida@collabora.com, a.hindborg@kernel.org,
	alex.gaynor@gmail.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,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH v2 1/2] rust: add udelay() function
Date: Wed, 22 Oct 2025 14:11:53 +0000	[thread overview]
Message-ID: <aPjmKSrETqrchW_e@google.com> (raw)
In-Reply-To: <20251022.193230.585171330619599845.fujita.tomonori@gmail.com>

On Wed, Oct 22, 2025 at 07:32:30PM +0900, FUJITA Tomonori wrote:
> On Tue, 21 Oct 2025 17:20:41 +0200
> "Danilo Krummrich" <dakr@kernel.org> wrote:
> 
> > On Tue Oct 21, 2025 at 5:13 PM CEST, Miguel Ojeda wrote:
> >> i.e. if they aren't sure what the value is, then I would prefer they
> >> clamp it explicitly on the callee side (or we provide an explicitly
> >> clamped version if it is a common case, but it seems to me runtime
> >> values are already the minority).
> > 
> > Absolutely! Especially given the context udelay() is introduced
> > (read_poll_timeout_atomic()), the compile time checked version is what we really
> > want.
> > 
> > Maybe we should even defer a runtime checked / clamped version until it is
> > actually needed.
> 
> Then perhaps something like this?
> 
> #[inline(always)]
> pub fn udelay(delta: Delta) {
>     build_assert!(
>         delta.as_nanos() >= 0 && delta.as_nanos() <= i64::from(bindings::MAX_UDELAY_MS) * 1_000_000
>     );

This is a bad idea. Using build_assert! assert for range checks works
poorly, as we found for register index bounds checks.

If you really want to check it at compile-time, you'll need a wrapper
type around Delta that can only be constructed with delays in the right
range.

Alice

  reply	other threads:[~2025-10-22 14:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-21  7:11 [PATCH v2 0/2] Add read_poll_count_atomic support FUJITA Tomonori
2025-10-21  7:11 ` [PATCH v2 1/2] rust: add udelay() function FUJITA Tomonori
2025-10-21 12:08   ` Danilo Krummrich
2025-10-21 14:39     ` Miguel Ojeda
2025-10-21 14:46       ` Danilo Krummrich
2025-10-21 14:58         ` Miguel Ojeda
2025-10-21 15:09           ` Danilo Krummrich
2025-10-21 15:13             ` Miguel Ojeda
2025-10-21 15:20               ` Danilo Krummrich
2025-10-22 10:32                 ` FUJITA Tomonori
2025-10-22 14:11                   ` Alice Ryhl [this message]
2025-10-23  5:19                     ` FUJITA Tomonori
2025-10-24  8:23                       ` Andreas Hindborg
2025-10-24  8:20                     ` Andreas Hindborg
2025-10-24  9:27                       ` Alice Ryhl
2025-10-24 19:05                         ` Miguel Ojeda
2025-10-26 13:11                           ` FUJITA Tomonori
2025-10-26 14:49                             ` Miguel Ojeda
2025-10-21  7:11 ` [PATCH v2 2/2] rust: Add read_poll_count_atomic function FUJITA Tomonori
2025-10-21 12:35   ` Danilo Krummrich
2025-10-21 14:05     ` Alice Ryhl
2025-10-21 16:02       ` Danilo Krummrich
2025-10-22 11:27         ` FUJITA Tomonori
2025-10-24  8:25       ` Andreas Hindborg
2025-10-24  9:19         ` Alice Ryhl
2025-10-23  5:24     ` FUJITA Tomonori

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=aPjmKSrETqrchW_e@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=gregkh@linuxfoundation.org \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=miguel.ojeda.sandonis@gmail.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.