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

[Alistair Popple]

On 2026-08-26 at 07:13 +1000, John Hubbard <jhubbard@xxxxxxxxxx> wrote...
> 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.

Ok. I thought maybe with GSP providing a lot of the HW abstraction we might have
been going somewhat in that direction. It's something I've seen done well in the
past on other products.

> > 
> > 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.

With careful design it can work, but you're right that probably isn't something
we're doing or want here and would make the experience worse.

> >> 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.

Sure. Two questions:

1) Do we also need to provide the decoded implementation value?
2) If we provide the decoded values why do we need to expose the chip-id at all?

Thanks.

 - Alistair

> thanks,
> -- 
> John Hubbard
>