If built on architectures with CONFIG_ARCH_DMA_ADDR_T_64BIT=y nova-core
produces that following build failures:

    error[E0308]: mismatched types
      --> drivers/gpu/nova-core/fb.rs:49:59
       |
    49 |         hal::fb_hal(chipset).write_sysmem_flush_page(bar, 
page.dma_handle())?;
       |                              -----------------------      
^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`
       |                              |
       |                              arguments to this method are incorrect
       |
    note: method defined here
      --> drivers/gpu/nova-core/fb/hal.rs:19:8
       |
    19 |     fn write_sysmem_flush_page(&self, bar: &Bar0, addr: u64) -> Result;
       |        ^^^^^^^^^^^^^^^^^^^^^^^
    help: you can convert a `u32` to a `u64`
       |
    49 |         hal::fb_hal(chipset).write_sysmem_flush_page(bar, 
page.dma_handle().into())?;
       |                                                                        
    +++++++

    error[E0308]: mismatched types
      --> drivers/gpu/nova-core/fb.rs:65:47
       |
    65 |         if hal.read_sysmem_flush_page(bar) == self.page.dma_handle() {
       |            -------------------------------    ^^^^^^^^^^^^^^^^^^^^^^ 
expected `u64`, found `u32`
       |            |
       |            expected because this is `u64`
       |
    help: you can convert a `u32` to a `u64`
       |
    65 |         if hal.read_sysmem_flush_page(bar) == 
self.page.dma_handle().into() {
       |                                                                     
+++++++

    error: this arithmetic operation will overflow
       --> drivers/gpu/nova-core/falcon.rs:469:23
        |
    469 |             .set_base((dma_start >> 40) as u16)
        |                       ^^^^^^^^^^^^^^^^^ attempt to shift right by 
`40_i32`, which would overflow
        |
        = note: `#[deny(arithmetic_overflow)]` on by default

This is due to the code making assumptions on the width of dma_addr_t to
be 64 bit.

While this could technically be handled, it is rather painful to deal
with, as the following example illustrates:

        pub(super) fn read_sysmem_flush_page_ga100(bar: &Bar0) -> DmaAddress {
            let addr = 
u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08())
                << FLUSH_SYSMEM_ADDR_SHIFT
                | 
u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
                    << FLUSH_SYSMEM_ADDR_SHIFT_HI;

            addr.try_into().unwrap_or_else(|_| {
                kernel::warn_on!(true);

                0
            })
        }

At the same time there's not much value for nova-core to support 32-bit,
given that the supported GPU architectures are Turing and later, hence
depend on CONFIG_64BIT.

Cc: John Hubbard <jhubb...@nvidia.com>
Reported-by: Miguel Ojeda <oj...@kernel.org>
Closes: https://lore.kernel.org/lkml/20250828160247.37492-1-oj...@kernel.org/
Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page")
Fixes: 69f5cd67ce41 ("gpu: nova-core: add falcon register definitions and base 
code")
Signed-off-by: Danilo Krummrich <d...@kernel.org>
---
 drivers/gpu/nova-core/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
index 8726d80d6ba4..20d3e6d0d796 100644
--- a/drivers/gpu/nova-core/Kconfig
+++ b/drivers/gpu/nova-core/Kconfig
@@ -1,5 +1,6 @@
 config NOVA_CORE
        tristate "Nova Core GPU driver"
+       depends on 64BIT
        depends on PCI
        depends on RUST
        depends on RUST_FW_LOADER_ABSTRACTIONS

base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
-- 
2.51.0

Reply via email to