[PATCH 0/2] rust, nova-core: use u64 variants of SZ_* constants

[PATCH 0/2] rust, nova-core: use u64 variants of SZ_* constants

[John Hubbard]

Hi,

This is based on the recently posted Blackwell/Hopper v6 series[1].

Although it doesn't really depend on that series, it's better to apply
it on top, in order to catch all of the cases, some of which were added
by that series.

[1] https://github.com/johnhubbard/linux/tree/nova-core-blackwell-v6


John Hubbard (2):
  rust: sizes: add u64 variants of SZ_* constants
  gpu: nova-core: use SZ_*_U64 constants from kernel::sizes

 drivers/gpu/nova-core/fb.rs     | 19 ++++++------
 drivers/gpu/nova-core/gsp/fw.rs | 23 +++++++--------
 drivers/gpu/nova-core/regs.rs   |  6 ++--
 rust/kernel/sizes.rs            | 51 +++++++++++++++++++++++++++++++++
 4 files changed, 72 insertions(+), 27 deletions(-)


base-commit: 0c794102e44c20df9a655b28245dd037f197cd69
-- 
2.53.0

[PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[John Hubbard]

Drivers that operate on 64-bit address spaces (GPU framebuffer layouts,
DMA regions, etc.) frequently need these size constants as a u64 type.
Today this requires repeated usize-to-u64 conversion calls like
usize_as_u64(SZ_1M) or u64::from_safe_cast(SZ_1M), which adds
boilerplate without any safety benefit.

Add u64-typed constants (SZ_1K_U64 through SZ_2G_U64) alongside the
existing usize constants. Every value fits in u64 (actually, within a
u32 for that matter), so the as-cast is always lossless.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 rust/kernel/sizes.rs | 51 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/rust/kernel/sizes.rs b/rust/kernel/sizes.rs
index 661e680d9330..a11c134be64e 100644
--- a/rust/kernel/sizes.rs
+++ b/rust/kernel/sizes.rs
@@ -48,3 +48,54 @@
 pub const SZ_1G: usize = bindings::SZ_1G as usize;
 /// 0x80000000
 pub const SZ_2G: usize = bindings::SZ_2G as usize;
+
+// `u64` variants of the size constants. These are the same values as the
+// `usize` constants above, but typed as `u64` to avoid repeated conversion
+// boilerplate in code that operates on 64-bit address spaces.
+//
+// CAST: every SZ_* value below fits in u64, so `as u64` is always lossless.
+
+/// [`SZ_1K`] as a [`u64`].
+pub const SZ_1K_U64: u64 = SZ_1K as u64;
+/// [`SZ_2K`] as a [`u64`].
+pub const SZ_2K_U64: u64 = SZ_2K as u64;
+/// [`SZ_4K`] as a [`u64`].
+pub const SZ_4K_U64: u64 = SZ_4K as u64;
+/// [`SZ_8K`] as a [`u64`].
+pub const SZ_8K_U64: u64 = SZ_8K as u64;
+/// [`SZ_16K`] as a [`u64`].
+pub const SZ_16K_U64: u64 = SZ_16K as u64;
+/// [`SZ_32K`] as a [`u64`].
+pub const SZ_32K_U64: u64 = SZ_32K as u64;
+/// [`SZ_64K`] as a [`u64`].
+pub const SZ_64K_U64: u64 = SZ_64K as u64;
+/// [`SZ_128K`] as a [`u64`].
+pub const SZ_128K_U64: u64 = SZ_128K as u64;
+/// [`SZ_256K`] as a [`u64`].
+pub const SZ_256K_U64: u64 = SZ_256K as u64;
+/// [`SZ_512K`] as a [`u64`].
+pub const SZ_512K_U64: u64 = SZ_512K as u64;
+/// [`SZ_1M`] as a [`u64`].
+pub const SZ_1M_U64: u64 = SZ_1M as u64;
+/// [`SZ_2M`] as a [`u64`].
+pub const SZ_2M_U64: u64 = SZ_2M as u64;
+/// [`SZ_4M`] as a [`u64`].
+pub const SZ_4M_U64: u64 = SZ_4M as u64;
+/// [`SZ_8M`] as a [`u64`].
+pub const SZ_8M_U64: u64 = SZ_8M as u64;
+/// [`SZ_16M`] as a [`u64`].
+pub const SZ_16M_U64: u64 = SZ_16M as u64;
+/// [`SZ_32M`] as a [`u64`].
+pub const SZ_32M_U64: u64 = SZ_32M as u64;
+/// [`SZ_64M`] as a [`u64`].
+pub const SZ_64M_U64: u64 = SZ_64M as u64;
+/// [`SZ_128M`] as a [`u64`].
+pub const SZ_128M_U64: u64 = SZ_128M as u64;
+/// [`SZ_256M`] as a [`u64`].
+pub const SZ_256M_U64: u64 = SZ_256M as u64;
+/// [`SZ_512M`] as a [`u64`].
+pub const SZ_512M_U64: u64 = SZ_512M as u64;
+/// [`SZ_1G`] as a [`u64`].
+pub const SZ_1G_U64: u64 = SZ_1G as u64;
+/// [`SZ_2G`] as a [`u64`].
+pub const SZ_2G_U64: u64 = SZ_2G as u64;
-- 
2.53.0

[PATCH 2/2] gpu: nova-core: use SZ_*_U64 constants from kernel::sizes

[John Hubbard]

Replace manual usize_as_u64(SZ_*) and u64::from_safe_cast(SZ_*)
conversions with the new SZ_*_U64 constants throughout fb.rs, gsp/fw.rs,
and regs.rs. This removes the conversion boilerplate and the now-unused
usize_as_u64 import in fb.rs.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/fb.rs     | 19 ++++++++-----------
 drivers/gpu/nova-core/gsp/fw.rs | 23 ++++++++++-------------
 drivers/gpu/nova-core/regs.rs   |  6 +++---
 3 files changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
index 5943db2b619b..1a84a15581a4 100644
--- a/drivers/gpu/nova-core/fb.rs
+++ b/drivers/gpu/nova-core/fb.rs
@@ -24,10 +24,7 @@
     firmware::gsp::GspFirmware,
     gpu::Chipset,
     gsp,
-    num::{
-        usize_as_u64,
-        FromSafeCast, //
-    },
+    num::FromSafeCast,
     regs,
 };
 
@@ -105,7 +102,7 @@ pub(crate) fn calc_non_wpr_heap_size(chipset: Chipset) -> u64 {
     hal::fb_hal(chipset)
         .non_wpr_heap_size()
         .map(u64::from)
-        .unwrap_or(usize_as_u64(SZ_1M))
+        .unwrap_or(SZ_1M_U64)
 }
 
 pub(crate) struct FbRange(Range<u64>);
@@ -136,8 +133,8 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
         if f.alternate() {
             let size = self.len();
 
-            if size < usize_as_u64(SZ_1M) {
-                let size_kib = size / usize_as_u64(SZ_1K);
+            if size < SZ_1M_U64 {
+                let size_kib = size / SZ_1K_U64;
                 f.write_fmt(fmt!(
                     "{:#x}..{:#x} ({} KiB)",
                     self.0.start,
@@ -145,7 +142,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
                     size_kib
                 ))
             } else {
-                let size_mib = size / usize_as_u64(SZ_1M);
+                let size_mib = size / SZ_1M_U64;
                 f.write_fmt(fmt!(
                     "{:#x}..{:#x} ({} MiB)",
                     self.0.start,
@@ -195,14 +192,14 @@ pub(crate) fn new(chipset: Chipset, bar: &Bar0, gsp_fw: &GspFirmware) -> Result<
 
         let vga_workspace = {
             let vga_base = {
-                const NV_PRAMIN_SIZE: u64 = usize_as_u64(SZ_1M);
+                const NV_PRAMIN_SIZE: u64 = SZ_1M_U64;
                 let base = fb.end - NV_PRAMIN_SIZE;
 
                 if hal.supports_display(bar) {
                     match regs::NV_PDISP_VGA_WORKSPACE_BASE::read(bar).vga_workspace_addr() {
                         Some(addr) => {
                             if addr < base {
-                                const VBIOS_WORKSPACE_SIZE: u64 = usize_as_u64(SZ_128K);
+                                const VBIOS_WORKSPACE_SIZE: u64 = SZ_128K_U64;
 
                                 // Point workspace address to end of framebuffer.
                                 fb.end - VBIOS_WORKSPACE_SIZE
@@ -222,7 +219,7 @@ pub(crate) fn new(chipset: Chipset, bar: &Bar0, gsp_fw: &GspFirmware) -> Result<
 
         let frts = {
             const FRTS_DOWN_ALIGN: Alignment = Alignment::new::<SZ_128K>();
-            const FRTS_SIZE: u64 = usize_as_u64(SZ_1M);
+            const FRTS_SIZE: u64 = SZ_1M_U64;
             let frts_base = vga_workspace.start.align_down(FRTS_DOWN_ALIGN) - FRTS_SIZE;
 
             FbRange(frts_base..frts_base + FRTS_SIZE)
diff --git a/drivers/gpu/nova-core/gsp/fw.rs b/drivers/gpu/nova-core/gsp/fw.rs
index 7834efc9095a..a9a86332664e 100644
--- a/drivers/gpu/nova-core/gsp/fw.rs
+++ b/drivers/gpu/nova-core/gsp/fw.rs
@@ -15,10 +15,7 @@
         Alignable,
         Alignment, //
     },
-    sizes::{
-        SZ_128K,
-        SZ_1M, //
-    },
+    sizes::*,
     transmute::{
         AsBytes,
         FromBytes, //
@@ -52,9 +49,9 @@ enum GspFwHeapParams {}
 // See Open RM: kgspCalculateGspFwHeapSize and related functions.
 //
 // 14MB for Hopper/Blackwell+.
-const GSP_FW_HEAP_PARAM_BASE_RM_SIZE_GH100: u64 = 14 * num::usize_as_u64(SZ_1M);
+const GSP_FW_HEAP_PARAM_BASE_RM_SIZE_GH100: u64 = 14 * SZ_1M_U64;
 // 142MB client alloc for ~188MB total.
-const GSP_FW_HEAP_PARAM_CLIENT_ALLOC_SIZE_GH100: u64 = 142 * num::usize_as_u64(SZ_1M);
+const GSP_FW_HEAP_PARAM_CLIENT_ALLOC_SIZE_GH100: u64 = 142 * SZ_1M_U64;
 // Hopper/Blackwell+ minimum heap size: 170MB (88 + 12 + 70).
 // See Open RM: GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MIN_MB for the base 88MB,
 // plus Hopper+ additions in kgspCalculateGspFwHeapSize_GH100.
@@ -88,7 +85,7 @@ fn client_alloc_size(chipset: Chipset) -> Result<u64> {
     /// Returns the amount of memory to reserve for management purposes for a framebuffer of size
     /// `fb_size`.
     fn management_overhead(fb_size: u64) -> Result<u64> {
-        let fb_size_gb = fb_size.div_ceil(u64::from_safe_cast(kernel::sizes::SZ_1G));
+        let fb_size_gb = fb_size.div_ceil(SZ_1G_U64);
 
         u64::from(bindings::GSP_FW_HEAP_PARAM_SIZE_PER_GB_FB)
             .saturating_mul(fb_size_gb)
@@ -110,9 +107,9 @@ impl LibosParams {
     const LIBOS2: LibosParams = LibosParams {
         carveout_size: num::u32_as_u64(bindings::GSP_FW_HEAP_PARAM_OS_SIZE_LIBOS2),
         allowed_heap_size: num::u32_as_u64(bindings::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MIN_MB)
-            * num::usize_as_u64(SZ_1M)
+            * SZ_1M_U64
             ..num::u32_as_u64(bindings::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MAX_MB)
-                * num::usize_as_u64(SZ_1M),
+                * SZ_1M_U64,
     };
 
     /// Version 3 of the GSP LIBOS (GA102+)
@@ -120,9 +117,9 @@ impl LibosParams {
         carveout_size: num::u32_as_u64(bindings::GSP_FW_HEAP_PARAM_OS_SIZE_LIBOS3_BAREMETAL),
         allowed_heap_size: num::u32_as_u64(
             bindings::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MIN_MB,
-        ) * num::usize_as_u64(SZ_1M)
+        ) * SZ_1M_U64
             ..num::u32_as_u64(bindings::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MAX_MB)
-                * num::usize_as_u64(SZ_1M),
+                * SZ_1M_U64,
     };
 
     /// Hopper/Blackwell+ GPUs need a larger minimum heap size than the bindings specify.
@@ -131,9 +128,9 @@ impl LibosParams {
     const LIBOS_HOPPER: LibosParams = LibosParams {
         carveout_size: num::u32_as_u64(bindings::GSP_FW_HEAP_PARAM_OS_SIZE_LIBOS3_BAREMETAL),
         allowed_heap_size: GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MIN_MB_HOPPER
-            * num::usize_as_u64(SZ_1M)
+            * SZ_1M_U64
             ..num::u32_as_u64(bindings::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MAX_MB)
-                * num::usize_as_u64(SZ_1M),
+                * SZ_1M_U64,
     };
 
     /// Returns the libos parameters corresponding to `chipset`.
diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
index d4efa6376acd..8d424dd23a5a 100644
--- a/drivers/gpu/nova-core/regs.rs
+++ b/drivers/gpu/nova-core/regs.rs
@@ -10,6 +10,7 @@
 use kernel::{
     io::Io,
     prelude::*,
+    sizes::*,
     time, //
 };
 
@@ -33,7 +34,6 @@
         Architecture,
         Chipset, //
     },
-    num::FromSafeCast,
 };
 
 // PMC
@@ -166,7 +166,7 @@ impl NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE {
     /// Returns the usable framebuffer size, in bytes.
     pub(crate) fn usable_fb_size(self) -> u64 {
         let size = (u64::from(self.lower_mag()) << u64::from(self.lower_scale()))
-            * u64::from_safe_cast(kernel::sizes::SZ_1M);
+            * SZ_1M_U64;
 
         if self.ecc_mode_enabled() {
             // Remove the amount of memory reserved for ECC (one per 16 units).
@@ -255,7 +255,7 @@ pub(crate) fn completed(self) -> bool {
 impl NV_USABLE_FB_SIZE_IN_MB {
     /// Returns the usable framebuffer size, in bytes.
     pub(crate) fn usable_fb_size(self) -> u64 {
-        u64::from(self.value()) * u64::from_safe_cast(kernel::sizes::SZ_1M)
+        u64::from(self.value()) * SZ_1M_U64
     }
 }
 
-- 
2.53.0

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Miguel Ojeda]

On Tue, Mar 10, 2026 at 3:31 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> +// CAST: every SZ_* value below fits in u64, so `as u64` is always lossless.

Nit:

    // CAST: Every `SZ_*` value below fits in `u64`, so `as u64` is
always lossless.

One alternative could be something like `sizes::u64::SZ_1M`, but if
you expect to mix `usize` and `u64` often then it may not be great.

Regarding adding the constants or not, I am ambivalent. On one hand, I
see the pain of repeating it; on the other hand, adding these only
works for particular values (i.e. we still need the safe casts around
anyway for other values).

By the way, why don't we use the safe cast here? They are `const fn`,
right? i.e. that would avoid the need to justify the cast and it would
serve to double-check the cast too.

By the way (x2), if we decide to go with the constants, we may want to
use a macro to generate most of the file, which could allow us to also
have the sizes as `u32` too, in case that is useful (in 32-bit
domains?).

Thanks!

Cheers,
Miguel

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Daniel Almeida]

> On 10 Mar 2026, at 10:51, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> On Tue, Mar 10, 2026 at 3:31 AM John Hubbard <jhubbard@nvidia.com> wrote:
>> 
>> +// CAST: every SZ_* value below fits in u64, so `as u64` is always lossless.
> 
> Nit:
> 
>    // CAST: Every `SZ_*` value below fits in `u64`, so `as u64` is
> always lossless.
> 
> One alternative could be something like `sizes::u64::SZ_1M`, but if
> you expect to mix `usize` and `u64` often then it may not be great.
> 
> Regarding adding the constants or not, I am ambivalent. On one hand, I
> see the pain of repeating it; on the other hand, adding these only
> works for particular values (i.e. we still need the safe casts around
> anyway for other values).
> 

I am not necessarily advocating one way or another, but as a further data
point: we also have a bit of this boilerplate scattered throughout Tyr.

It’d be nice to cut down on it, however it ends up being done in the end.

I do think that sizes::u64::SZ_1M does look better than what’s been proposed
in the patch, though.

> By the way, why don't we use the safe cast here? They are `const fn`,
> right? i.e. that would avoid the need to justify the cast and it would
> serve to double-check the cast too.
> 
> By the way (x2), if we decide to go with the constants, we may want to
> use a macro to generate most of the file, which could allow us to also
> have the sizes as `u32` too, in case that is useful (in 32-bit
> domains?).
> 
> Thanks!
> 
> Cheers,
> Miguel
> 

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Danilo Krummrich]

On Tue Mar 10, 2026 at 2:51 PM CET, Miguel Ojeda wrote:
> On Tue, Mar 10, 2026 at 3:31 AM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> +// CAST: every SZ_* value below fits in u64, so `as u64` is always lossless.
>
> Nit:
>
>     // CAST: Every `SZ_*` value below fits in `u64`, so `as u64` is
> always lossless.
>
> One alternative could be something like `sizes::u64::SZ_1M`, but if
> you expect to mix `usize` and `u64` often then it may not be great.

I have a slight preference towards this. It also shoudn't be that bad if we need
both, as we could just keep the prefix, i.e. u64::SZ_1M.

> Regarding adding the constants or not, I am ambivalent. On one hand, I
> see the pain of repeating it; on the other hand, adding these only
> works for particular values (i.e. we still need the safe casts around
> anyway for other values).

In a lot of cases we won't need to go back and forth with those values, as all
of the DRM infrastructure works with u64. So, there'd be quite a lot of overhead
if everytime we want to initialize something in GPUVM, GPU Buddy, TTM, etc. with
one of the SZ_* constants, i.e. we'd need to repeat u64::from_safe_cast(SZ_*)
over and over again. This is the main reason why I proposed to have u64 variants
in the first place.

Technically, if they are not needed for anything else, we could also make them
GPU infrastructure, e.g. gpu::SZ_*. Additionally, we could have GPU specific
usize and isize types.

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Danilo Krummrich]

On Tue Mar 10, 2026 at 3:31 AM CET, John Hubbard wrote:
> Drivers that operate on 64-bit address spaces (GPU framebuffer layouts,
> DMA regions, etc.) frequently need these size constants as a u64 type.
> Today this requires repeated usize-to-u64 conversion calls like
> usize_as_u64(SZ_1M) or u64::from_safe_cast(SZ_1M), which adds
> boilerplate without any safety benefit.
>
> Add u64-typed constants (SZ_1K_U64 through SZ_2G_U64) alongside the
> existing usize constants. Every value fits in u64 (actually, within a
> u32 for that matter), so the as-cast is always lossless.
>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>

Feel free to add:

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/all/DGB9G697GSWO.3VBFGU5MKFPMR@kernel.org/
Link: https://lore.kernel.org/all/DGHI8WRKBQS9.38910L6FIIZTE@kernel.org/

As mentioned in the other thread, we could also make this GPU infrastructure and
have GPU specific usize / isize types.

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Miguel Ojeda]

On Tue, Mar 10, 2026 at 2:51 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Regarding adding the constants or not, I am ambivalent. On one hand, I
> see the pain of repeating it; on the other hand, adding these only
> works for particular values (i.e. we still need the safe casts around
> anyway for other values).

I see both Daniel and Danilo would like to have them, so that is a
strong indicator we likely want them. Thanks both for the replies!

Whether we go for `u64::` or not, please feel free to add:

  Acked-by: Miguel Ojeda <ojeda@kernel.org>

Either way, please consider the suggestion about using `const fn` in
the definitions here -- or if you prefer, we can put it as a "good
first issue" for a separate future improvement.

Thanks!

Cheers,
Miguel

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Danilo Krummrich]

On Tue Mar 10, 2026 at 9:20 PM CET, Miguel Ojeda wrote:
> Whether we go for `u64::` or not

The more I think about it, the more I tend towards not going for u64::, at least
not directly.

The point really is that we differentiate between GPU (or more generally device)
address space size and CPU address space size.

So, I think what we really want is an abstraction of a usize type for GPUs (or
devices in general).

A corresponding implementation of SZ_* would just follow those.

In any case, I think we should implement those with a macro.

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Danilo Krummrich]

On Tue Mar 10, 2026 at 9:47 PM CET, Danilo Krummrich wrote:
> On Tue Mar 10, 2026 at 9:20 PM CET, Miguel Ojeda wrote:
>> Whether we go for `u64::` or not
>
> The more I think about it, the more I tend towards not going for u64::, at least
> not directly.
>
> The point really is that we differentiate between GPU (or more generally device)
> address space size and CPU address space size.
>
> So, I think what we really want is an abstraction of a usize type for GPUs (or
> devices in general).

Forgot to mention, the background of this is that existing DRM components, such
as GPUVM, Buddy, etc. just use u64 as a common denominator. However, this
becomes annoying when the corresponding device is u32 (or even smaller outside
of DRM). Because then we have all the fallible conversions on the other end
where the driver interacts with the HW.

So, on the Rust side I think we want to abstract this, such that drivers can
choose the actual device size type and the corresponding APIs just work with
this type and store the actual value in the backing u64 internally, but hand it
out as the actual type the driver passed in originally.

> A corresponding implementation of SZ_* would just follow those.
>
> In any case, I think we should implement those with a macro.

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Miguel Ojeda]

On Tue, Mar 10, 2026 at 9:55 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Forgot to mention, the background of this is that existing DRM components, such
> as GPUVM, Buddy, etc. just use u64 as a common denominator. However, this
> becomes annoying when the corresponding device is u32 (or even smaller outside
> of DRM). Because then we have all the fallible conversions on the other end
> where the driver interacts with the HW.
>
> So, on the Rust side I think we want to abstract this, such that drivers can
> choose the actual device size type and the corresponding APIs just work with
> this type and store the actual value in the backing u64 internally, but hand it
> out as the actual type the driver passed in originally.

I see, thanks for that context -- yes, if the types are different and
known, it would be better to abstract over the right one.

(And perhaps it may even make sense to use newtypes too, depending on
the details.)

Cheers,
Miguel

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[John Hubbard]

On 3/10/26 3:08 PM, Miguel Ojeda wrote:
> On Tue, Mar 10, 2026 at 9:55 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> Forgot to mention, the background of this is that existing DRM components, such
>> as GPUVM, Buddy, etc. just use u64 as a common denominator. However, this
>> becomes annoying when the corresponding device is u32 (or even smaller outside
>> of DRM). Because then we have all the fallible conversions on the other end
>> where the driver interacts with the HW.
>>
>> So, on the Rust side I think we want to abstract this, such that drivers can
>> choose the actual device size type and the corresponding APIs just work with
>> this type and store the actual value in the backing u64 internally, but hand it
>> out as the actual type the driver passed in originally.
> 
> I see, thanks for that context -- yes, if the types are different and
> known, it would be better to abstract over the right one.
> 
> (And perhaps it may even make sense to use newtypes too, depending on
> the details.)

It might. Because GpuAddr is a bit vague, whereas FbAddr is always going
to be u64.

OK, I think a define_size!() macro that implements a DeviceSize trait works
here. We still end up converting call sites to use sizes::u64::SZ_1M, once
DeviceSize is in scope.

And then later, one can build on top of that with things such as
<T: DeviceSize>, and such.

I'll post a v2, assuming that this sounds about right.

thanks,
-- 
John Hubbard

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[John Hubbard]

On 3/10/26 3:13 PM, John Hubbard wrote:
> On 3/10/26 3:08 PM, Miguel Ojeda wrote:
>> On Tue, Mar 10, 2026 at 9:55 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>>
>>> Forgot to mention, the background of this is that existing DRM components, such
>>> as GPUVM, Buddy, etc. just use u64 as a common denominator. However, this
>>> becomes annoying when the corresponding device is u32 (or even smaller outside
>>> of DRM). Because then we have all the fallible conversions on the other end
>>> where the driver interacts with the HW.
>>>
>>> So, on the Rust side I think we want to abstract this, such that drivers can
>>> choose the actual device size type and the corresponding APIs just work with
>>> this type and store the actual value in the backing u64 internally, but hand it
>>> out as the actual type the driver passed in originally.
>>
>> I see, thanks for that context -- yes, if the types are different and
>> known, it would be better to abstract over the right one.
>>
>> (And perhaps it may even make sense to use newtypes too, depending on
>> the details.)
> 
> It might. Because GpuAddr is a bit vague, whereas FbAddr is always going
> to be u64.
> 
> OK, I think a define_size!() macro that implements a DeviceSize trait works
> here. We still end up converting call sites to use sizes::u64::SZ_1M, once

ah, correction, make that u64::SZ_1M, when DeviceSize is in scope.
(No sizes:: prefix.)

> DeviceSize is in scope.
> 
> And then later, one can build on top of that with things such as
> <T: DeviceSize>, and such.
> 
> I'll post a v2, assuming that this sounds about right.
> 
> thanks,

thanks,
-- 
John Hubbard

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[Alexandre Courbot]

On Tue Mar 10, 2026 at 10:51 PM JST, Miguel Ojeda wrote:
> On Tue, Mar 10, 2026 at 3:31 AM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> +// CAST: every SZ_* value below fits in u64, so `as u64` is always lossless.
>
> Nit:
>
>     // CAST: Every `SZ_*` value below fits in `u64`, so `as u64` is
> always lossless.
>
> One alternative could be something like `sizes::u64::SZ_1M`, but if
> you expect to mix `usize` and `u64` often then it may not be great.

How about an extension trait for integer types with all the `SZ_*`
defined as constants?

That would allow easy implementation for more integer types, like
`Bounded`. Because "64 bit" address spaces are often actually less than
that, and we might want to work with `Bounded` for them.

Re: [PATCH 1/2] rust: sizes: add u64 variants of SZ_* constants

[John Hubbard]

On 3/11/26 1:01 AM, Alexandre Courbot wrote:
> On Tue Mar 10, 2026 at 10:51 PM JST, Miguel Ojeda wrote:
>> On Tue, Mar 10, 2026 at 3:31 AM John Hubbard <jhubbard@nvidia.com> wrote:
>>>
>>> +// CAST: every SZ_* value below fits in u64, so `as u64` is always lossless.
>>
>> Nit:
>>
>>     // CAST: Every `SZ_*` value below fits in `u64`, so `as u64` is
>> always lossless.
>>
>> One alternative could be something like `sizes::u64::SZ_1M`, but if
>> you expect to mix `usize` and `u64` often then it may not be great.
> 
> How about an extension trait for integer types with all the `SZ_*`
> defined as constants?

I believe that's what I have locally, with DeviceSize, so I'll go
ahead and post it as v2, and let's see how it looks.

> 
> That would allow easy implementation for more integer types, like
> `Bounded`. Because "64 bit" address spaces are often actually less than
> that, and we might want to work with `Bounded` for them.

thanks,
-- 
John Hubbard