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 <[email protected]>
>> ---
>> 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,
