Re: [PATCH v2 3/5] drm: nova: Add GETPARAM parameter to read the GPU chipset

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Jul 9, 2026 at 2:35 PM CEST, Alexandre Courbot wrote:
> On Thu Jul 9, 2026 at 5:52 PM JST, Alistair Popple wrote:
>> @@ -82,39 +83,39 @@ fn try_from(value: u32) -> Result<Self, Self::Error> {
>>  
>>  define_chipset!({
>>      // Turing
>> -    TU102 = 0x162,
>> -    TU104 = 0x164,
>> -    TU106 = 0x166,
>> -    TU117 = 0x167,
>> -    TU116 = 0x168,
>> +    TU102 = uapi::drm_nova_chipset_NOVA_DRM_CHIPSET_TU102,
>> +    TU104 = uapi::drm_nova_chipset_NOVA_DRM_CHIPSET_TU104,
>> +    TU106 = uapi::drm_nova_chipset_NOVA_DRM_CHIPSET_TU106,
>> +    TU117 = uapi::drm_nova_chipset_NOVA_DRM_CHIPSET_TU117,
>> +    TU116 = uapi::drm_nova_chipset_NOVA_DRM_CHIPSET_TU116,
>
> If we are going to remove the actual values, let's at least generate the
> right-hand side in the macro as it is just verbose without bringing any
> new information. The following diff lets you remove the `= uapi::...`
> for each chipset declaration.

I was about to propose the same thing, the right-hand side is just noise.

> The UAPI definitions come technically from nova-drm (and are defined as
> such), which introduces a dependency of sorts from nova-core to
> nova-drm. I'm not saying this is a problem, but mentioning it as we want
> to make that decision consciously.

It is the other way around, both nova-core (mostly indirectly) and nova-drm
(directly) implement the uAPI contract and hence obviously depend on this
contract.

The chipset value that is exposed to userspace is produced by nova-core, not by
nova-drm; nova-drm just passes it through.

So, this is not a "we randomly reuse the uAPI enum" kind of situation, it is
more about making nova-core commit to the contract that it has to uphold.

> I also think the introduction of UAPI variants and modification of
> `define_chipset` should be its own patch, as these are pretty
> mechanical.

Yes, it should be.

Thanks,
Danilo