Re: [PATCH v5 05/11] drm: nova: Add an info ioctl

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

On Tue Sep 1, 2026 at 12:38 PM CEST, Danilo Krummrich wrote:
> On Fri Aug 28, 2026 at 5:35 AM CEST, Alistair Popple wrote:
>> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
>> index 0c12ef145981..740466af268d 100644
>> --- a/drivers/gpu/nova-core/gpu.rs
>> +++ b/drivers/gpu/nova-core/gpu.rs
>> @@ -138,6 +138,11 @@ pub(crate) const fn arch(self) -> Architecture {
>>          }
>>      }
>>  
>> +    /// Returns the implementation identifier of this chipset.
>> +    pub(crate) const fn implementation(self) -> u32 {
>> +        self as u32 & 0xf
>> +    }
>
> I missed this part in my previous reply. Besides being a bit unfortunate that we
> have to reimplement what boot42.implementation() already gives us, I think the
> value is not overly useful anyway.
>
> I get the intent, architecture and implementation complement each other, but in
> practice we are not interested in the implementation bits, but either in a
> unique chip identifier or the architecture.
>
> If you look at the nova-core code you will find exactly that, we either check
> for a specific chip or an architecture and I think userspace will be intersted
> in the same.
>
> So, I think the uAPI should provide the architecture and a unique chip
> identifier.
>
> Before we circle back, I know that the unique chip identifier in nova-core
> technically contains the architecture for obvious reasons, but my point has
> always been that we can give the decoded architecture to userspace and not
> require it to know about and extract it from the chip identifier we consider
> opaque in the uAPI.

IOW, we should not think of this in terms of the numbers/values exposed by some
register. All the users (including nova-core itself) don't really care about the
values behind the enum, how it composes and how it is related to other values,
that's just an implementation detail.

All users care about is that they have an architecture and chip identifier to
compare against. I.e. there's no value letting userspace think of the chip
identifier as architecture/implementation tuple, since the implementation value
by itself is rather useless.