On Wed Jul 8, 2026 at 11:52 PM PDT, Alexandre Courbot wrote: > The recently introduced `GspBootContext` is useful in at least two > other places: > > - As a replacement for the sequencer's `GspSequencerParams`, > - As the main parameter of `Gsp::unload`, for symmetry with `Gsp::boot`. > > This symmetry can be further exploited to make `Gsp::boot` and > `Gsp::unload` generic over the exact boot context required for the > current chip. Doing so requires some more preliminary work that goes > beyond this series, but this groundwork is needed regardless. > > Another cleanup that can be performed as a consequence is the removal of > the `BootUnloadGuard`. This type is cumbersome as it holds extra > references to the boot context, making it difficult to make some of > these references mutable (as we want to do with the `Falcon`s that > should require exclusive access to load and run firmware). Furthermore, > it is only needed a single time in `Gsp::boot`, and is inadequate for > handling errors occurring in HALs. > > Based on Eliot's feedback on v4, the series then removes the last > remnants of the boot procedure leaking outside of the HALs, and > consolidates everything within the GSP and FSP HALs. > > This series applies on the latest `drm-rust-next`. > > Signed-off-by: Alexandre Courbot <[email protected]>
Pushed to drm-rust-next! Thanks all.
