Re: [PATCH v3 1/9] gpu: nova-core: gsp: add NV_STATUS error code bindings

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

On Mon Apr 6, 2026 at 4:55 AM JST, John Hubbard wrote:
> On 3/25/26 5:13 AM, Eliot Courtney wrote:
>> Add bindgen generated constants for NV_STATUS. This is used for RM
>> control messages.
>> 
>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>> ---
>>   drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs | 144 ++++++++++++++++++++++
>>   1 file changed, 144 insertions(+)
>> 
>> diff --git a/drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs b/drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs
>> index 334e8be5fde8..dd37a7fd58c6 100644
>> --- a/drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs
>> +++ b/drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs
>> @@ -379,6 +379,150 @@ pub struct NV2080_CTRL_CMD_FB_GET_FB_REGION_INFO_PARAMS {
>>       pub __bindgen_padding_0: [u8; 4usize],
>>       pub fbRegion: [NV2080_CTRL_CMD_FB_GET_FB_REGION_FB_REGION_INFO; 16usize],
>>   }
>> +pub const NV_OK: _bindgen_ty_4 = 0;
>> +pub const NV_ERR_GENERIC: _bindgen_ty_4 = 65535;
> ...
>> +pub const NV_ERR_RESOURCE_RETIREMENT_ERROR: _bindgen_ty_4 = 134;
>> +pub const NV_WARN_HOT_SWITCH: _bindgen_ty_4 = 65537;
>> +pub const NV_WARN_INCORRECT_PERFMON_DATA: _bindgen_ty_4 = 65538;
>
> If we go with pulling these ERR_ and WARN_ items in directly
> from GSP-RM, then we should also update Alistair's bindgen
> helper, or my fork of it:
>
>      https://github.com/apopple-nvidia/nova-gsp-binding-generator/commits/main/
>      https://github.com/johnhubbard/nova-gsp-binding-generator/commits/main

Yep, I have local changes to these which I will send. These bindings
updates were all generated based on Alistair's bindgen helper.

> However, the deeper problem is that the C headers define these as
> #defines, so bindgen emits pub const u32 items. The hand-written
> NvStatus enum in patch 2 has no compile-time relationship to them. When
> Open RM adds a new code, the Rust enum silently absorbs it into
> Unknown(u32) -> Err(EIO) with no compiler diagnostic.

Yes, this is unfortunate, although we still need to manually think about
the mapping at some point.

One thing I can try is to remove the Unknown(u32) variant here and use
TryFrom (which we will end up using with FromPrimitive later) - then
at least we will get errors if a new discriminant is added.

>
> Which brings us back to a feature that Alex Courbot and Danilo have been
> asking for, and I've been treating as "nice to have, maybe next month"
> for apparently too long. And that is, generating Rust bindings directly
> from the GSP-RM build system.

Sounds good to me as long as we can generate this mapping at the same
time and have it fail if a new one is added.

> I think it's time, yes?

What would this look like / any agreement on what the shape of this
would look like yet? 

>
>> +pub const NV_WARN_MISMATCHED_SLAVE: _bindgen_ty_4 = 65539;
>> +pub const NV_WARN_MISMATCHED_TARGET: _bindgen_ty_4 = 65540;
>> +pub const NV_WARN_MORE_PROCESSING_REQUIRED: _bindgen_ty_4 = 65541;
>> +pub const NV_WARN_NOTHING_TO_DO: _bindgen_ty_4 = 65542;
>> +pub const NV_WARN_NULL_OBJECT: _bindgen_ty_4 = 65543;
>> +pub const NV_WARN_OUT_OF_RANGE: _bindgen_ty_4 = 65544;
>> +pub type _bindgen_ty_4 = ffi::c_uint;
>>   #[repr(C)]
>>   #[derive(Debug, Copy, Clone, MaybeZeroable)]
>>   pub struct NV2080_CTRL_GPU_GET_GID_INFO_PARAMS {
>> 
>
> thanks,