From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Boqun Feng" <boqun@kernel.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 4/5] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command upon unloading
Date: Thu, 23 Apr 2026 11:32:09 +0900 [thread overview]
Message-ID: <DI06KFG7C6P7.1NR2L62JY2RSF@nvidia.com> (raw)
In-Reply-To: <DHZMHF1YVBI4.F11YKDDKBNTQ@nvidia.com>
On Wed Apr 22, 2026 at 7:47 PM JST, Alexandre Courbot wrote:
> On Tue Apr 21, 2026 at 11:27 PM JST, Alexandre Courbot wrote:
> <snip>
>>>> + dev_dbg!(dev, "GSP shut down\n");
>>>> +
>>>> + Ok(())
>>>> + }
>>>> }
>>>> diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
>>>> index c80df421702c..fb94460c451e 100644
>>>> --- a/drivers/gpu/nova-core/gsp/commands.rs
>>>> +++ b/drivers/gpu/nova-core/gsp/commands.rs
>>>> @@ -237,3 +237,39 @@ pub(crate) fn gpu_name(&self) -> core::result::Result<&str, GpuNameError> {
>>>> pub(crate) fn get_gsp_info(cmdq: &Cmdq, bar: &Bar0) -> Result<GetGspStaticInfoReply> {
>>>> cmdq.send_command(bar, GetGspStaticInfo)
>>>> }
>>>> +
>>>> +pub(crate) struct UnloadingGuestDriver {
>>>> + suspend: bool,
>>>> +}
>>>
>>> This feels like it only makes sense to call from within the gsp module,
>>> so I wonder if it can be pub(super) (prolly a few others in this file
>>> could be too, ofc not relevant for this series).
>>
>> I'll review that, we do want to limit visibility as much as possible.
>
> Mmm looking more closely I am not sure this is something we want/can do.
> As the driver expands, it looks likely that some of these types will be
> used outside of the `gsp` module - in particular some of the responses
> can be used outside, I think this actually happens with the MM series.
>
> So I think I will keep the visibility as-is for now.
I think some will be used outside yeah. For UnloadingGuestDriver do you
reckon it makes sense for it to be called outside of the gsp module? It
looks like it should only happen on unload and needs to be a part of a
bunch of other tear down code to work.
next prev parent reply other threads:[~2026-04-23 2:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 6:16 [PATCH v2 0/5] gpu: nova-core: run unload sequence upon unbinding Alexandre Courbot
2026-04-21 6:16 ` [PATCH v2 1/5] rust: add warn_on_err macro Alexandre Courbot
2026-04-21 7:07 ` Eliot Courtney
2026-04-21 6:16 ` [PATCH v2 2/5] gpu: nova-core: use " Alexandre Courbot
2026-04-21 7:09 ` Eliot Courtney
2026-04-21 6:16 ` [PATCH v2 3/5] gpu: nova-core: do not import firmware commands into GSP command module Alexandre Courbot
2026-04-21 8:58 ` Eliot Courtney
2026-04-21 6:16 ` [PATCH v2 4/5] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command upon unloading Alexandre Courbot
2026-04-21 9:42 ` Eliot Courtney
2026-04-21 14:27 ` Alexandre Courbot
2026-04-22 10:47 ` Alexandre Courbot
2026-04-23 2:32 ` Eliot Courtney [this message]
2026-04-21 6:16 ` [PATCH v2 5/5] gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding Alexandre Courbot
2026-04-22 6:01 ` Eliot Courtney
2026-04-22 10:46 ` Alexandre Courbot
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=DI06KFG7C6P7.1NR2L62JY2RSF@nvidia.com \
--to=ecourtney@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
/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