wireguard-linux/drivers/gpu/nova-core/gsp/hal.rs, branch stable

gpu: nova-core: update firmware module info for TLV images

2026-08-05T23:54:12Z

Now that nova-core loads the TLV firmware images, update the firmware module info to specify those files. Also remove FIRMWARE_VERSION as it is no longer used. Signed-off-by: Timur Tabi Reviewed-by: Alexandre Courbot Tested-by: Alexandre Courbot Link: https://patch.msgid.link/20260731201017.2580713-9-ttabi@nvidia.com Signed-off-by: Danilo Krummrich

gpu: nova-core: split FbLayout into FSP and non-FSP versions

2026-08-05T05:20:37Z

`FbLayout` is currently used for both pre and post FSP architectures. It contains ranges for each region of framebuffer, but on post FSP architectures, only the size is actually used. The region locations are decided by ACR, which runs as part of the GSP-FMC, not by the driver. The driver only provides the sizes. So, for post FSP architectures `FbLayout` contains essentially guesses for the offsets. Instead, make separate types so that we only store the information that's actually needed, rather than keeping around offsets that may not be correct. Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-4-ac858b6a1935@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext

2026-07-15T23:00:53Z

`Falcon` instances retain references tied to the lifetime of the bound GPU. `GspBootContext` currently uses that same lifetime for its own borrows of the `Falcon` instances and other references. But these lifetimes are independent: the references captured by a `Falcon` remain valid for the GPU lifetime, while the context only borrows the `Falcon` for the duration of a boot or unload operation. This distinction is hidden for shared references by covariance, but cannot be ignored anymore if the context carries mutable references to GPU subdevices, as will happen for the `Fsp` and the `Falcon`s. Thus, give `GspBootContext` separate lifetimes for its subdevice borrows and the GPU resources captured by those subdevices, and update its users accordingly. Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-12-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: gsp: pass GspBootContext mutably

2026-07-15T23:00:52Z

We want to move the `Fsp` instance into `Gpu`, which will require passing it as a mutable reference in `GspBootContext`, since `Fsp::boot_fmc` is a mutable method. In order to use the mutable references it contains, `GspBootContext` must also be mutable. We will also follow up by making some methods of the `Falcon`s mutable, which also requires passing them as mutable references. Thus, make the `GspBootContext` passed to `Gsp::boot` and `Gsp::unload` mutable, and pass mutable references to it to the GSP boot HAL methods. Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-11-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: move GSP firmware files decision to GSP HAL

2026-07-15T23:00:52Z

The files to give the `ModInfoBuilder` depend on the chipset; this is HAL information, so move it there. Doing so lets us remove the `uses_fsp` and `needs_fwsec_bootloader` ad-hoc methods of `Chipset`. Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-9-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL

2026-07-15T23:00:52Z

By being in the TU102 HAL, we already know that the GSP boot method is the SEC2 Booter, so the only variable is whether the FWSEC bootloader is used or not. Since `Chipset` also includes the variants that boot FSP, querying it for that information introduces a potential code path (a chipset that boots via FSP) that the current code doesn't handle. Turn the use of the FWSEC bootloader into a property of the `Tu102` HAL, and give GA102+ chipsets their own instance with that property set to `false`. This removes the invalid code path and the only use of `Chipset` is now to load the correct firmware files. This also removes some uses of the `Chipset::needs_fwsec_bootloader` method and prepares the ground for removing it. Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-8-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: gsp: pass GspBootContext to unload methods

2026-07-15T23:00:52Z

`GspBootContext` contains the resources required to boot the GSP. As it turns out, this is also the context required for unloading it. Reflect that fact by replacing the arguments of `Gsp::unload` and `UnloadBundle::run` with the `GspBootContext`. This symmetry between `Gsp::boot` and `Gsp::unload` will also be convenient when we want to make these methods generic over the boot context corresponding to the boot method used. Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-4-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: gsp: replace BootUnloadGuard with local handlers

2026-07-15T23:00:52Z

When adding the GSP unload capability, we introduced `BootUnloadGuard` to automatically call `Gsp::unload` whenever an error occurred during the boot process, in order to try to reset the GSP to a valid state. This approach is not well-suited to the errors that may occur in HALs: by definition, an error occurring in the HAL means that the GSP is not booted; yet the first thing that `Gsp::unload` does is queue a shutdown message to the GSP, which will inevitably result in a timeout when done from a HAL. Furthermore, `BootUnloadGuard` is problematic because it holds additional references to the boot context, notably the `Falcon`s. These extra references stand in the way of making some of the `Falcon`'s methods mutable, since those methods would require exclusive access. As this behavior is only needed in one place, introducing dedicated types for it is distracting and unnecessary. Thus, remove `BootUnloadGuard` and adopt a two-level error handling strategy: - HALs are free to handle their errors as they see fit (most likely, by running their unload bundle if it is ready by the time of the error), - `Gsp::boot` uses a `ScopeGuard` that runs `Gsp::unload`, since the GSP should be up and running by the time `GspHal::boot` has returned. Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-3-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: falcon: store bar and dev in falcon

2026-06-29T12:36:52Z

Store the bound device and `BAR0` mapping in `Falcon` instead of passing them through every `Falcon` operation. This simplifies the `Falcon` API and removes repeated `dev`/`bar` plumbing from reset, load, boot, mailbox, DMA, and GSP/FSP-specific Falcon helpers. `FalconHal` now receives a reference to a `Falcon` and uses its methods and members instead of passing them individually. Suggested-by: Alexandre Courbot Link: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/Storing.20driver-bound.20references.20into.20sub-devices/near/599137882 Signed-off-by: Tim Kovalenko Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260625-drm-bar-refactor-v2-1-9db6b890d92e@proton.me Signed-off-by: Alexandre Courbot

gpu: nova-core: consolidate GSP boot parameters into GspBootContext

2026-06-17T13:06:13Z

The GspHal trait methods boot() and post_boot() accept a long list of individual parameters (dev, bar, chipset, gsp_falcon, sec2_falcon) that are threaded through the entire GSP boot call chain. This makes the signatures unwieldy and difficult to extend as new boot-time context (e.g. vGPU state) is introduced. Introduce a GspBootContext struct that bundles the common boot parameters into a single object, and refactor the GspHal trait to accept &GspBootContext instead of individual arguments. The struct also exposes a dev() helper with proper lifetime annotation so that HAL implementations can extract the device reference without reborrowing constraints. Update both TU102 and GH100 HAL implementations to extract their required parameters from the context struct, and simplify the call sites in Gsp::boot() accordingly. Signed-off-by: Zhi Wang Link: https://patch.msgid.link/20260604114339.1565660-7-zhiw@nvidia.com [acourbot: pass `GspBootContext` by value to `Gsp::boot`.] [acourbot: deconstruct `GspBootContext` in `Gsp::boot` to simplify diff.] Signed-off-by: Alexandre Courbot