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

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

On Tue Aug 25, 2026 at 9:13 AM CEST, Alistair Popple wrote:
> I'm not particularly wedded to either approach but I think the approach is
> either:
>
> 1) Keep the chip_id opaque, user-space looks up arch/implementation/etc. from a
>    lookup table as required.

Why? The kernel already has the information, so we don't need a lookup table?

> 2) Keep the current scheme of just exposing the chip_id and letting user-space
>    decode it assuming the register layout won't change.
>
> In either case user-space needs to figure out arch/implementation/etc.
>
> For (1) the kernel should not be responsible for decoding arch because if you're
> assuming the register layout can change arbitrarily then the it can't reliably
> figure out the arch anyway.

If the kernel can't figure out the architecture of a card, it means that the
chip isn't known by the kernel. Without that, how can it boot the firmware,
etc.?

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

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.