From: sashiko-bot@kernel.org
To: "Alexandre Courbot" <acourbot@nvidia.com>
Cc: ojeda@kernel.org, dri-devel@lists.freedesktop.org,
"Danilo Krummrich" <dakr@kernel.org>
Subject: Re: [PATCH v4 05/13] gpu: nova-core: gsp: centralize missing unload bundle warnings
Date: Mon, 29 Jun 2026 14:20:06 +0000 [thread overview]
Message-ID: <20260629142007.8E3E71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629-nova-bootcontext-v4-5-5539d8469590@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Moving the unload bundle warning to `Gsp::boot` using `hal.boot(...)?.or_else(...)` drops the warning on error paths and is dead code for `Gh100`.
--
commit 6422f17d0c05bd4c3b60d0655dea96518aadd1a5
Author: Alexandre Courbot <acourbot@nvidia.com>
gpu: nova-core: gsp: centralize missing unload bundle warnings
This commit moves the warning emitted when the unload bundle cannot be
constructed from the Tu102-specific boot code to the generic Gsp::boot
method so it applies to all boot methods.
> diff --git a/drivers/gpu/nova-core/gsp/boot.rs b/drivers/gpu/nova-core/gsp/boot.rs
> index 75054424a9516..430ffc57b1366 100644
> --- a/drivers/gpu/nova-core/gsp/boot.rs
> +++ b/drivers/gpu/nova-core/gsp/boot.rs
> @@ -56,7 +56,15 @@ pub(crate) fn boot(
> let wpr_meta = Coherent::init(dev, GFP_KERNEL, GspFwWprMeta::new(&gsp_fw, &fb_layout))?;
>
> // Perform the chipset-specific boot sequence, and retrieve the unload bundle.
> - let unload_bundle = hal.boot(&self, &ctx, &fb_layout, &wpr_meta)?;
> + let unload_bundle = hal.boot(&self, &ctx, &fb_layout, &wpr_meta)?.or_else(|| {
[Severity: Medium]
Will this `.or_else()` block be skipped if `hal.boot()` returns an error
due to the `?` operator?
For example, if `Gh100::boot()` returns an `Err` directly when it fails to
build its bundle (e.g., KBox::new failure) rather than returning `Ok(None)`,
it seems this block would be completely unreachable, contrary to the commit
message's goal of applying it to all boot methods.
Likewise for `Tu102`, if `Sec2UnloadBundle::build()` fails and results in
`None`, but a subsequent step in `Tu102::boot()` fails and returns an `Err`,
the immediate error propagation would swallow these warnings.
> + dev_warn!(dev, "The GSP won't be able to unload properly on unbind.\n");
> + dev_warn!(
> + dev,
> + "The GPU will need to be reset before the driver can bind again.\n"
> + );
> +
> + None
> + });
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-nova-bootcontext-v4-0-5539d8469590@nvidia.com?part=5
next prev parent reply other threads:[~2026-06-29 14:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:09 [PATCH v4 00/13] gpu: nova-core: consolidate and streamline GSP boot process Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 01/13] gpu: nova-core: gsp: sequencer: use GspBootContext Alexandre Courbot
2026-06-29 14:22 ` sashiko-bot
2026-06-29 14:09 ` [PATCH v4 02/13] gpu: nova-core: gsp: sequencer: do not store sequence into GspSequencer Alexandre Courbot
2026-06-29 14:19 ` sashiko-bot
2026-06-29 14:09 ` [PATCH v4 03/13] gpu: nova-core: gsp: replace BootUnloadGuard with local handlers Alexandre Courbot
2026-06-29 14:21 ` sashiko-bot
2026-07-01 2:54 ` Eliot Courtney
2026-07-06 10:00 ` Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 04/13] gpu: nova-core: gsp: pass GspBootContext to unload methods Alexandre Courbot
2026-07-01 3:57 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 05/13] gpu: nova-core: gsp: centralize missing unload bundle warnings Alexandre Courbot
2026-06-29 14:20 ` sashiko-bot [this message]
2026-07-01 4:06 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 06/13] gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method Alexandre Courbot
2026-07-01 4:15 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 07/13] gpu: nova-core: gsp: turn FWSEC execution " Alexandre Courbot
2026-07-01 4:16 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 08/13] gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 09/13] gpu: nova-core: introduce GspBootMethod Alexandre Courbot
2026-07-02 2:28 ` Eliot Courtney
2026-07-07 1:21 ` Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 10/13] gpu: nova-core: avoid repeated calls to pci::Device::as_ref Alexandre Courbot
2026-06-29 14:17 ` sashiko-bot
2026-07-01 6:38 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 11/13] gpu: nova-core: gsp: pass GspBootContext mutably Alexandre Courbot
2026-07-01 6:40 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 12/13] gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext Alexandre Courbot
2026-06-29 14:22 ` sashiko-bot
2026-07-01 6:52 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 13/13] gpu: nova-core: store Fsp instance in Gpu Alexandre Courbot
2026-06-29 14:27 ` sashiko-bot
2026-07-01 6:46 ` Eliot Courtney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260629142007.8E3E71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=acourbot@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox