kernel/drivers/gpu/nova-core/gsp/boot.rs, branch master

rust: dma: use pointer projection infra for `dma_{read,write}` macro

2026-03-07T22:06:20Z

Current `dma_read!`, `dma_write!` macros also use a custom `addr_of!()`-based implementation for projecting pointers, which has soundness issue as it relies on absence of `Deref` implementation on types. It also has a soundness issue where it does not protect against unaligned fields (when `#[repr(packed)]` is used) so it can generate misaligned accesses. This commit migrates them to use the general pointer projection infrastructure, which handles these cases correctly. As part of migration, the macro is updated to have an improved surface syntax. The current macro have dma_read!(a.b.c[d].e.f) to mean `a.b.c` is a DMA coherent allocation and it should project into it with `[d].e.f` and do a read, which is confusing as it makes the indexing operator integral to the macro (so it will break if you have an array of `CoherentAllocation`, for example). This also is problematic as we would like to generalize `CoherentAllocation` from just slices to arbitrary types. Make the macro expects `dma_read!(path.to.dma, .path.inside.dma)` as the canonical syntax. The index operator is no longer special and is just one type of projection (in additional to field projection). Similarly, make `dma_write!(path.to.dma, .path.inside.dma, value)` become the canonical syntax for writing. Another issue of the current macro is that it is always fallible. This makes sense with existing design of `CoherentAllocation`, but once we support fixed size arrays with `CoherentAllocation`, it is desirable to have the ability to perform infallible indexing as well, e.g. doing a `[0]` index of `[Foo; 2]` is okay and can be checked at build-time, so forcing falliblity is non-ideal. To capture this, the macro is changed to use `[idx]` as infallible projection and `[idx]?` as fallible index projection (those syntax are part of the general projection infra). A benefit of this is that while individual indexing operation may fail, the overall read/write operation is not fallible. Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Reviewed-by: Benno Lossin Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260302164239.284084-4-gary@kernel.org [ Capitalize safety comments; slightly improve wording in doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich

gpu: nova-core: add Falcon HAL method load_method()

2026-01-24T01:48:59Z

Some GPUs do not support using DMA to transfer code/data from system memory to Falcon memory, and instead must use programmed I/O (PIO). Add a function to the Falcon HAL to indicate whether a given GPU's Falcons support DMA for this purpose. Signed-off-by: Timur Tabi Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260122222848.2555890-10-ttabi@nvidia.com [acourbot@nvidia.com: add short code to call into the HAL.] [acourbot@nvidia.com: make `dma_load` private as per feedback.] Signed-off-by: Alexandre Courbot

gpu: nova-core: add missing newlines to several print strings

2026-01-12T13:44:06Z

Although the dev_xx!() macro calls do not technically require terminating newlines for the format strings, they should be added anyway to maintain consistency, both within Rust code and with the C versions. Signed-off-by: Timur Tabi Reviewed-by: John Hubbard Link: https://patch.msgid.link/20260107201647.2490140-2-ttabi@nvidia.com Signed-off-by: Danilo Krummrich

gpu: nova-core: preserve error information in gpu_name()

2026-01-12T13:11:04Z

Change gpu_name() to return a Result instead of an Option. This avoids silently discarding error information when parsing the GPU name string from the GSP. Update the callsite to log a warning with the error details on failure, rather than just displaying "invalid GPU name". Suggested-by: Danilo Krummrich Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260108005811.86014-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich

gpu: nova-core: fw: get rid of redundant Result in GspFirmware::new()

2025-12-29T16:54:31Z

In GspFirmware::new(), utilize pin_init_scope() to get rid of the Result in the returned Result> which is unnecessarily redundant. Reviewed-by: Joel Fernandes Link: https://patch.msgid.link/20251218155239.25243-2-dakr@kernel.org Signed-off-by: Danilo Krummrich

gpu: nova-core: gsp: Retrieve GSP static info to gather GPU information

2025-11-15T12:54:18Z

After GSP initialization is complete, retrieve the static configuration information from GSP-RM. This information includes GPU name, capabilities, memory configuration, and other properties. On some GPU variants, it is also required to do this for initialization to complete. Signed-off-by: Alistair Popple Co-developed-by: Joel Fernandes Signed-off-by: Joel Fernandes Reviewed-by: Lyude Paul [acourbot@nvidia.com: properly abstract the command's bindings, add relevant methods, make str_from_null_terminated return an Option, fix size of GPU name array.] Co-developed-by: Alexandre Courbot Signed-off-by: Alexandre Courbot Message-ID: <20251114195552.739371-14-joelagnelf@nvidia.com>

gpu: nova-core: gsp: Wait for gsp initialization to complete

2025-11-15T12:54:18Z

This adds the GSP init done command to wait for GSP initialization to complete. Once this command has been received the GSP is fully operational and will respond properly to normal RPC commands. Signed-off-by: Alistair Popple Co-developed-by: Joel Fernandes Signed-off-by: Joel Fernandes Reviewed-by: Lyude Paul [acourbot@nvidia.com: move new definitions to end of commands.rs, rename to `wait_gsp_init_done` and remove timeout argument.] Signed-off-by: Alexandre Courbot Message-ID: <20251114195552.739371-13-joelagnelf@nvidia.com>

gpu: nova-core: Implement the GSP sequencer

2025-11-15T12:05:50Z

Implement the GSP sequencer which culminates in INIT_DONE message being received from the GSP indicating that the GSP has successfully booted. This is just initial sequencer support, the actual commands will be added in the next patches. Signed-off-by: Joel Fernandes [acourbot@nvidia.com: move GspSequencerInfo definition before its impl blocks and rename it to GspSequence, adapt imports in sequencer.rs to new formatting rules, remove `timeout` argument to harmonize with other commands.] Signed-off-by: Alexandre Courbot Message-ID: <20251114195552.739371-8-joelagnelf@nvidia.com>

gpu: nova-core: gsp: Boot GSP

2025-11-14T11:25:57Z

Boot the GSP to the RISC-V active state. Completing the boot requires running the CPU sequencer which will be added in a future commit. Reviewed-by: Lyude Paul Signed-off-by: Alistair Popple Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-15-8ae4058e3c0e@nvidia.com>

gpu: nova-core: gsp: Add SetRegistry command

2025-11-14T11:25:57Z

Add support for sending the SetRegistry command, which is critical to GSP initialization. The RM registry is serialized into a packed format and sent via the command queue. For now only three parameters which are required to boot GSP are hardcoded. In the future a kernel module parameter will be added to enable other parameters to be added. Signed-off-by: Alistair Popple [acourbot@nvidia.com: split into its own patch.] Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-12-8ae4058e3c0e@nvidia.com>