Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Early failures in `GspHal::boot` return a dummy `EAGAIN` error for the unload bundle, triggering misleading warnings in `Gsp::boot`. --
commit 59b7c0f9ed708bf2f09f8548faf948cfa1adfc96 Author: Alexandre Courbot <[email protected]> gpu: nova-core: gsp: make unload take GspBootContext This patch refactors Gsp::unload to accept GspBootContext instead of individual resource arguments. This reflects that the resources required to boot the GSP are also needed for unloading it. > diff --git a/drivers/gpu/nova-core/gsp/boot.rs > b/drivers/gpu/nova-core/gsp/boot.rs > index 3f11eaec26c78..336ad23c96f9b 100644 > --- a/drivers/gpu/nova-core/gsp/boot.rs > +++ b/drivers/gpu/nova-core/gsp/boot.rs [ ... ] > @@ -102,7 +100,7 @@ pub(crate) fn boot( > dev_err!(dev, "GSP boot failed with error {:?}\n", e); > > // Ignore errors during unload; we will return the error > that happened during boot. > - let _ = self.unload(dev, bar, gsp_falcon, ctx.sec2_falcon, > unload_bundle); > + let _ = self.unload(ctx, unload_bundle); [Severity: Low] If an early operation in the HAL boot paths fails before unload_bundle is properly initialized (such as Vbios::new() failing in Tu102::boot(), or missing fsp in Gh100::boot()), does unload_bundle retain a dummy Err(EAGAIN) value? If so, does this cause the inspect_err() on unload_bundle to unconditionally trigger and log misleading warnings that falsely claim the GPU will need a reset even for these early initialization failures? > > Err(e) > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
