Re: [PATCH v2 6/6] gpu: nova-core: gsp: cmdq: add the GMC receive path

["Eliot Courtney" <ecourtney@nvidia.com>]

On Fri Nov 6, 2026 at 4:06 PM JST, Alexandre Courbot wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> GSP-RM answers a GMC request with a GMC message whose command word
> carries the response flag and the id of the request, and whose sequence
> number is that of the request. It also raises GMC events, named by a
> command id. During boot, the load-and-execute events arrive while the
> driver is waiting for the GSP_INIT reply, and GSP-RM only answers once
> they have been handled.
>
> Add the receive side of the gmc sub-module, mirroring the
> already-existing rpc sub-module.
>
> The transport cannot produce GMC messages yet: the r570 queue element
> header does not carry the type of the message it transports, so the Gmc
> variant of GspParsedMessage is only constructed once the switch to r000
> makes the transport dispatch on the NVDM type. The RPC receive path and
> drain() account for it by logging unclaimed GMC messages.
>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> Co-developed-by: Alexandre Courbot <acourbot@nvidia.com>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---

[...]

> +    fn await_gmc_reply<C: CommandToGsp>(
> +        &mut self,
> +        seq: u32,
> +        on_event: impl Fn(&GmcMessage<'_>) -> Result,
> +    ) -> Result<Result<C::Reply, u32>>
> +    where
> +        C::Reply: MessageFromGsp,
> +        // This allows all error types, including `Infallible`, to be used for `InitError`.
> +        Error: From<<C::Reply as MessageFromGsp>::InitError>,
> +    {
> +        let dev = self.dev;
> +
> +        self.await_msg_with(|message| -> Result<Option<Result<C::Reply, u32>>> {

optional nit: add a TODO to say we should make and use an NvStatus enum
instead of u32 here. 

I had renamed my original nvstatus enum I sent ages ago, here's the
original [1].

The previous concern [2] for landing this is that when the bindings change
we may forget to update the enum. Now that nvstatus is being returned as
part of a stable API surface I think that concern is less strong,
because it'll have to be both append only and backwards compatible, so
we could get a nvstatus value we don't know about from newer firmwares,
which we'd have to handle somehow anyway (so forgetting to update the
enum necessarily can't cause an issue).

Anyway I say it's optional nit because I think it'll be a long while
before we want to differentiate behaviour based on anything other than
success/failure in nvstatus.

[1]: https://lore.kernel.org/all/20260227-rmcontrol-v1-2-86648e4869f9@nvidia.com/
[2]:  https://lore.kernel.org/all/fd010f7a-6d0d-4faf-bdea-23bac608f03e@nvidia.com/

Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>