[PATCH] [v2] peci: Remove dependency on x86 CPU variables

[Guenter Roeck]

On Fri, Feb 20, 2026 at 09:51:21AM -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen at linux.intel.com>
> 
> tl;dr: The non-x86 PECI driver #includes an arch/x86 header.  This is
> ostensibly to avoid duplicating CPU model number constants, but the
> result is complexity and duplicated *code* which is a far worse fate
> than duplicated constants.
> 
> Remove the PECI dependency on arch/x86 by adding a list of supported
> "target" CPU models in the driver.
> 
> This is only compile tested.
> 
> Long version:
> 
> == Background ==
> 
> The "PECI" driver runs on non-x86 hardware inside an x86 system.  It
> talks to the x86 CPU. The PECI hardware has different features based on
> platform generations and uses the CPU model to control feature
> detections.
> 
> Basically, instead of a PCI or USB device ID that a USB or PCI driver
> would use, the PECI driver uses the CPU model (and family).
> 
> The arch/x86 code unsurprisingly has a list of CPU model numbers and the
> PECI code currently reuses that list. But the arch/x86 list is
> maintained in the "Display" format which is different than the binary
> format that CPUID (and PECI hardware) uses.
> 
> == Problem ==
> 
> The end result is that the PECI code #includes the arch/x86 constants
> header and then duplicates some code that transforms the CPUID to the
> "Display" format. This is fragile because it's easy for us x86 folks to
> break the PECI driver when assuming that arch/x86 is x86-only.
> 
> == Solution ==
> 
> Remove the arch/x86 dependency. Instead of duplicating the
> CPUID=>Display functionality, just duplicate the constants.
> 
> Also rename the formerly "x86_vfm" variables. They are not in the VFM
> format any longer. They are purely device IDs.  Name them appropriately.
> 
> The result is a net code removal. The only downside is that the PECI
> folks need to add a #define whenever there is a new CPU model. But, they
> need to go add new CPU model to the driver explicitly *anyway*.
> 
> == Notes ==
> 
> One little wrinkle in this is that the CPU identifier that comes back
> from the PECI hardware contains the CPU stepping just like
> CPUID.01H:EAX. But the stepping is ignored by the PECI driver.
> 
> So, the PECI_INTEL_* identifiers are just defined with the stepping
> shifted off the beginning. They could have been defined with a 0 there
> and then have the stepping masked somewhere.
> 
> Signed-off-by: Dave Hansen <dave.hansen at linux.intel.com>
> Reviewed-by: Sohil Mehta <sohil.mehta at intel.com>
> Cc: Iwona Winiarska <iwona.winiarska at intel.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: linux-hwmon at vger.kernel.org
> Cc: openbmc at lists.ozlabs.org
> Cc: Tony Luck <tony.luck at intel.com>
> Cc: x86 at kernel.org
> Cc: Thomas Gleixner <tglx at kernel.org>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: Borislav Petkov <bp at alien8.de>
> Cc: "H. Peter Anvin" <hpa at zytor.com>
> 
> --
> 
> Changes from v1:
>  * Fix wrong Haswell model/family
>  * Fix peci_device kernel doc
> ---
> 
>  b/drivers/hwmon/peci/cputemp.c |   10 ++++-----

For hwmon:

Acked-by: Guenter Roeck <linux at roeck-us.net>

Guenter