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

On Tue Aug 25, 2026 at 2:03 PM CEST, Alistair Popple wrote:
> On the other hand we don't need to ignore the lessons of Nouveau either and try
> and refactor everything - I agree there are plenty of UAPI choices that should
> and will be different and we shouldn't limit ourselves - but if an interface has
> been working well for 30 years and hasn't been causing anyone any issues then
> perhaps we should just stick with it for Nova as well?

IMO this answers the wrong question; I think the questions should be:

  - Why should we expose an encoded register value to userspace now that we have
    the chance to not do so and hide that implementation detail?

  - What happens if it ever breaks?

As for the first one, I don't really see how it is a benefit to let userspace
decode it independently. It's better to have a single source of truth.

Besides that, we may also need to expose the chip major/minor revision at some
point, which can't be decoded from the chipid value. For this we'd need to
expose the full BOOT_42 register. Which is where we already have a precedent
where things changed from BOOT_0 in the past.

More in general, passing encoded values from registers to userspace isn't the
best practice.

Of course, userspace has to know about how the hardware works - I mean, that's
why we expose chipid, arch, etc. in the first place - but it doesn't (and
shouldn't) need to know how the parts work the kernel is responsible for.