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
