Re: [PATCH 2/4] gpu: nova-core: gsp: add the GMC API header

[Eliot Courtney]

On Tue Nov 3, 2026 at 9:02 AM JST, Alexandre Courbot wrote:
> From: John Hubbard <jhubbard@xxxxxxxxxx>
>
> The r000 firmware carries GSP-RM's boot protocol, and its newer
> interfaces in general, over the GMC (GPU Management Controller) API:
> messages that follow the queue element header with a GMC API header
> instead of an RPC header.
>
> Add the GmcApiHeader type as a newtype over the GMCAPI_HEADER binding,
> so we can define the GMC send and receive paths in the following
> patches.
>
> [ acourbot: wrap the bindings type instead of redefining it; make
>   `status` return an `Option` to avoid returning a value whose semantics
>   are ambiguous.]
>
> Assisted-by: LLM
> Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>
> Co-developed-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
> Signed-off-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
> ---

[...]

> +/// Header of a GMC (GPU Management Controller) API message.
> +///
> +/// In a queue element, it follows the queue element header and precedes the payload of the
> +/// command.
> +#[repr(transparent)]
> +#[expect(dead_code)]

The build breaks on rust 1.85 here, see rust-lang/rust#154377. I also
had to work around this in the NVKV series. It's broken in a few other
places so worth checking each patch on 1.85 imo

> +pub(crate) struct GmcApiHeader {
> +    inner: r000_00::GMCAPI_HEADER,
> +}
> +
> +#[expect(dead_code)]
> +impl GmcApiHeader {
> +    /// Creates the header of a request for `command`, sent with sequence number `sequence` and
> +    /// followed by `payload_size` bytes of payload.
> +    ///
> +    /// `max_reply_size` is the largest reply the sender accepts, and zero for a request that
> +    /// GSP-RM does not answer.

This is a bit confusing imo since we have zero reply length commands
that do get a response. I would just say that commands that do not
expect a reply or expect an reply with an empty payload (so just for the
status value) should pass zero here.

Otherwise,

Reviewed-by: Eliot Courtney <ecourtney@xxxxxxxxxx>