rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Benno Lossin" <lossin@kernel.org>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
	"Ben Skeggs" <bskeggs@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	<linux-kernel@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
	<nouveau@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v5 04/23] rust: add new `num` module with `PowerOfTwo` type
Date: Sat, 14 Jun 2025 21:09:57 +0200	[thread overview]
Message-ID: <DAMHRVOA2T1Q.OM6T75HPFO60@kernel.org> (raw)
In-Reply-To: <20250612-nova-frts-v5-4-14ba7eaf166b@nvidia.com>

On Thu Jun 12, 2025 at 4:01 PM CEST, Alexandre Courbot wrote:
> diff --git a/rust/kernel/num.rs b/rust/kernel/num.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..ee0f67ad1a89e69f5f8d2077eba5541b472e7d8a
> --- /dev/null
> +++ b/rust/kernel/num.rs
> @@ -0,0 +1,173 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Numerical and binary utilities for primitive types.
> +
> +use crate::build_assert;
> +use core::borrow::Borrow;
> +use core::fmt::Debug;
> +use core::hash::Hash;
> +use core::ops::Deref;
> +
> +/// An unsigned integer which is guaranteed to be a power of 2.
> +#[derive(Debug, Clone, Copy)]
> +#[repr(transparent)]

Let's add a `# Safety` section with the invariant that `T` is a power of
2.

Maybe we should even have an `Int` trait for the different integer types
that we constrain `T` to.

> +pub struct PowerOfTwo<T>(T);
> +
> +macro_rules! power_of_two_impl {
> +    ($($t:ty),+) => {
> +        $(
> +            impl PowerOfTwo<$t> {
> +                /// Validates that `v` is a power of two at build-time, and returns it wrapped into
> +                /// `PowerOfTwo`.
> +                ///
> +                /// A build error is triggered if `v` cannot be asserted to be a power of two.
> +                ///
> +                /// # Examples
> +                ///
> +                /// ```
> +                /// use kernel::num::PowerOfTwo;
> +                ///
> +                /// let v = PowerOfTwo::<u32>::new(256);
> +                /// assert_eq!(v.value(), 256);
> +                /// ```
> +                #[inline(always)]
> +                pub const fn new(v: $t) -> Self {
> +                    build_assert!(v.count_ones() == 1);
> +                    Self(v)
> +                }

We also probably want an `unsafe new_unchecked(v: $t) -> Self`. It can
still use a `debug_assert!` to verify the value.

> +
> +                /// Validates that `v` is a power of two at runtime, and returns it wrapped into
> +                /// `PowerOfTwo`.
> +                ///
> +                /// `None` is returned if `v` was not a power of two.
> +                ///
> +                /// # Examples
> +                ///
> +                /// ```
> +                /// use kernel::num::PowerOfTwo;
> +                ///
> +                /// assert_eq!(PowerOfTwo::<u32>::try_new(16).unwrap().value(), 16);
> +                /// assert_eq!(PowerOfTwo::<u32>::try_new(15), None);
> +                /// ```
> +                #[inline(always)]
> +                pub const fn try_new(v: $t) -> Option<Self> {
> +                    match v.count_ones() {
> +                        1 => Some(Self(v)),
> +                        _ => None,
> +                    }
> +                }
> +
> +                /// Returns the value of this instance.
> +                ///
> +                /// It is guaranteed to be a power of two.
> +                ///
> +                /// # Examples
> +                ///
> +                /// ```
> +                /// use kernel::num::PowerOfTwo;
> +                ///
> +                /// let v = PowerOfTwo::<u32>::new(256);
> +                /// assert_eq!(v.value(), 256);
> +                /// ```
> +                #[inline(always)]
> +                pub const fn value(&self) -> $t {

Since this type is `Copy`, we should use `self` here instead of `&self`.


Why not add

    if !self.0.is_power_of_two() {
        unsafe { ::core::hint::unreachable_unchecked() }
    }

here?

> +                    self.0
> +                }
> +
> +                /// Returns the mask corresponding to `self.value() - 1`.
> +                #[inline(always)]
> +                pub const fn mask(&self) -> $t {
> +                    self.0.wrapping_sub(1)

And then use `self.value()` here instead?

(we could even use `self.value() - 1`, since the optimizer can remove
the overflow check: https://godbolt.org/z/nvGaozGMW but wrapping_sub is
fine. The optimizations will most likely be more useful in other
arithmetic with `.value()`)

> +                }
> +
> +                /// Aligns `self` down to `alignment`.
> +                ///
> +                /// # Examples
> +                ///
> +                /// ```
> +                /// use kernel::num::PowerOfTwo;
> +                ///
> +                /// assert_eq!(PowerOfTwo::<u32>::new(0x1000).align_down(0x4fff), 0x4000);
> +                /// ```
> +                #[inline(always)]
> +                pub const fn align_down(self, value: $t) -> $t {
> +                    value & !self.mask()
> +                }
> +
> +                /// Aligns `value` up to `self`.
> +                ///
> +                /// Wraps around to `0` if the requested alignment pushes the result above the
> +                /// type's limits.
> +                ///
> +                /// # Examples
> +                ///
> +                /// ```
> +                /// use kernel::num::PowerOfTwo;
> +                ///
> +                /// assert_eq!(PowerOfTwo::<u32>::new(0x1000).align_up(0x4fff), 0x5000);
> +                /// assert_eq!(PowerOfTwo::<u32>::new(0x1000).align_up(0x4000), 0x4000);
> +                /// assert_eq!(PowerOfTwo::<u32>::new(0x1000).align_up(0x0), 0x0);
> +                /// assert_eq!(PowerOfTwo::<u16>::new(0x100).align_up(0xffff), 0x0);
> +                /// ```
> +                #[inline(always)]
> +                pub const fn align_up(self, value: $t) -> $t {
> +                    self.align_down(value.wrapping_add(self.mask()))
> +                }
> +            }
> +        )+
> +    };
> +}
> +
> +power_of_two_impl!(usize, u8, u16, u32, u64, u128);
> +
> +impl<T> Deref for PowerOfTwo<T> {
> +    type Target = T;
> +
> +    fn deref(&self) -> &Self::Target {
> +        &self.0
> +    }
> +}
> +
> +impl<T> PartialEq for PowerOfTwo<T>
> +where
> +    T: PartialEq,
> +{
> +    fn eq(&self, other: &Self) -> bool {
> +        self.0 == other.0
> +    }
> +}
> +
> +impl<T> Eq for PowerOfTwo<T> where T: Eq {}
> +
> +impl<T> PartialOrd for PowerOfTwo<T>
> +where
> +    T: PartialOrd,
> +{
> +    fn partial_cmp(&self, other: &Self) -> Option<core::cmp::Ordering> {
> +        self.0.partial_cmp(&other.0)
> +    }
> +}
> +
> +impl<T> Ord for PowerOfTwo<T>
> +where
> +    T: Ord,
> +{
> +    fn cmp(&self, other: &Self) -> core::cmp::Ordering {
> +        self.0.cmp(&other.0)
> +    }
> +}
> +
> +impl<T> Hash for PowerOfTwo<T>
> +where
> +    T: Hash,
> +{
> +    fn hash<H: core::hash::Hasher>(&self, state: &mut H) {
> +        self.0.hash(state);
> +    }
> +}

Can't these traits also be implemented using the derive macros?

---
Cheers,
Benno

> +
> +impl<T> Borrow<T> for PowerOfTwo<T> {
> +    fn borrow(&self) -> &T {
> +        &self.0
> +    }
> +}


  parent reply	other threads:[~2025-06-14 19:10 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 14:01 [PATCH v5 00/23] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 01/23] rust: dma: expose the count and size of CoherentAllocation Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 02/23] rust: make ETIMEDOUT error available Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 03/23] rust: sizes: add constants up to SZ_2G Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 04/23] rust: add new `num` module with `PowerOfTwo` type Alexandre Courbot
2025-06-12 15:07   ` Boqun Feng
2025-06-12 20:00     ` John Hubbard
2025-06-12 20:05       ` Boqun Feng
2025-06-12 20:08         ` John Hubbard
2025-06-12 20:12           ` Boqun Feng
2025-06-13 14:16     ` Alexandre Courbot
2025-06-13 15:25       ` Boqun Feng
2025-06-14 17:08       ` Boqun Feng
2025-06-16  5:14         ` Alexandre Courbot
2025-06-14 17:31   ` Boqun Feng
2025-06-16  5:19     ` Alexandre Courbot
2025-06-14 19:09   ` Benno Lossin [this message]
2025-06-15 13:32   ` Miguel Ojeda
2025-06-16  5:13     ` Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 05/23] rust: num: add the `fls` operation Alexandre Courbot
2025-06-14 19:16   ` Benno Lossin
2025-06-16  6:41     ` Alexandre Courbot
2025-06-18 19:24       ` Benno Lossin
2025-06-19 13:26         ` Alexandre Courbot
2025-06-19 13:28           ` Benno Lossin
2025-06-15  9:37   ` Miguel Ojeda
2025-06-15 10:51     ` Alexandre Courbot
2025-06-15 10:58       ` Alexandre Courbot
2025-06-15 13:25         ` Miguel Ojeda
2025-06-16  6:36           ` Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 06/23] gpu: nova-core: use absolute paths in register!() macro Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 07/23] gpu: nova-core: add delimiter for helper rules " Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 08/23] gpu: nova-core: expose the offset of each register as a type constant Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 09/23] gpu: nova-core: allow register aliases Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 10/23] gpu: nova-core: increase BAR0 size to 16MB Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 11/23] gpu: nova-core: add helper function to wait on condition Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 12/23] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 13/23] gpu: nova-core: add DMA object struct Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 14/23] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 15/23] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-06-17 16:33   ` Danilo Krummrich
2025-06-18  5:26     ` Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 16/23] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 17/23] gpu: nova-core: vbios: Add base support for VBIOS construction and iteration Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 18/23] gpu: nova-core: vbios: Add support to look up PMU table in FWSEC Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 19/23] gpu: nova-core: vbios: Add support for FWSEC ucode extraction Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 20/23] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 21/23] gpu: nova-core: add types for patching firmware binaries Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 22/23] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-06-12 14:01 ` [PATCH v5 23/23] gpu: nova-core: load and " Alexandre Courbot
2025-06-18 20:23   ` Danilo Krummrich
2025-06-18 20:24     ` Danilo Krummrich
2025-06-19 12:35       ` Alexandre Courbot
2025-06-19 12:43         ` Danilo Krummrich
2025-06-17 20:14 ` [PATCH v5 00/23] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Danilo Krummrich
2025-06-18  8:25   ` Alexandre Courbot
2025-06-18 20:14 ` Danilo Krummrich
2025-06-19  7:14   ` Alexandre Courbot

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=DAMHRVOA2T1Q.OM6T75HPFO60@kernel.org \
    --to=lossin@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bskeggs@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).