Re: [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

On 8/25/26 1:53 PM, Danilo Krummrich wrote:
> On Tue Aug 25, 2026 at 9:13 AM CEST, Alistair Popple wrote:
...>> For example if someone plugs a shiny new card with a different chip_id
>> register layout into a machine running an older kernel they could get an
>> incorrect arch which would be confusing. Users would get upset if for example
>> ShinyNewCard got reported as being Turing say.
> 
> If the kernel can't deal with a chip it should never succeed probing and never
> expose any information to userspace in the first place.

Agreed.

We had also some discussion about this point during the BOOT0/BOOT42
change-over. And we arrived at that same conclusion back then: don't
let PCI probe succeed on an unknown new chip.

> 
> nova-core does enforce this already; if a chipid can't be matched against an
> architecture it won't compile, and if the chipid is not known by nova-core it
> will fail to probe.
> 
> Note that nova-core binds by vendor + class, not specific PCI device IDs, so the
> chipset check is our only gate against unknown hardware.
> 
> If we'd hypothetically remove that gate and just allow trying to probe unknown
> hardware with the boot sequence of just assuming some default with the latest
> supported architecture, it would potentially be an even worse user experience,
> where instead of a clear rejection of the hardware a user might experience
> security/stability issues.
> 
>> So I think it makes sense to keep this decoding in user-space regardless of
>> whether that's exposed via documented opaque chip IDs and lookup tables for
>> arch/implementation or by a commitment to keep the chip ID register layout the
>> same.
> 
> I still don't see much value in letting userspace decode this again, nor do I
> think lookup tables are necessary.
> 
> If the driver succeeds to probe for a device we already did decode things, so
> there's no need for userspace to do it again or know about this.

Also agreed here. It's hard to see any advantage in decoding in both
user space and kernel.

thanks,
-- 
John Hubbard