linuxkpi: Define `VFM_*()` macros in <asm/cpu_device_id.h>

[dumbbell]

Summary

They use another set of constants and macros in <asm/intel-family.h>.

All these macros are defined regardless of the architecture, even though they are specific to x86. Perhaps we should restrict them using #ifdefs.

The amdgpu DRM driver started to used VFM_MODEL() and the INTEL_*LAKE* constants in Linux 6.12.x.

This is part of the update of DRM drivers to Linux 6.12.81.

Sponsored by: The FreeBSD Foundation

[bz]

I have no idea about these but I assume you got that right.

[dumbbell]

I copied them from Linux because they are all part of the public KPI and I don’t see how to "reimplement" them from their name (they are also not documented). I think they are trivial enough to not cause any harm.

[dumbbell]

@emaste: Do you think that me copying these macros and constants from Linux could be a problem?

[olce]

Given the spec inferred by reading this code, a lot of programmers would produce the same code when presented with that spec, so I don't think that they are the same really poses a problem (probably, these lines are not even copyrightable; but IANAL).

At some point, I'd like to make available to all kernel code the BITS_VALUE(), BITS_WITH_VALUE() and SET_BITS_VALUE() I created for sys/x86/cpufreq/hwpstate_amd.c in order to avoid all these shifts. GENMASK() seems a valuable interface addition as well.

sys/compat/linuxkpi/common/include/asm/intel-family.h

11–15

These constants (INTEL_FAM6_ROCKETLAKE) seem redundant.

In Linux, they have been removed end of 2024 by commit x86/cpu/vfm: Delete all the *_FAM6_ CPU #defines.
I guess we probably need to maintain them still because of older DRM drivers?

To avoid the redundancy, they could be converted to using VFM_MODEL(), e.g.:

#define	INTEL_FAM6_ALDERLAKE		VFM_MODEL(INTEL_ALDERLAKE)

But given there are only a few of them, that they are immediately visibly consistent and anyway are to be deleted at some point, it's probably not worth the trouble.