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

[Winiarska, Iwona]

On Fri, 2026-02-20 at 09:51 -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxx>
> Reviewed-by: Sohil Mehta <sohil.mehta@xxxxxxxxx>
> Cc: Iwona Winiarska <iwona.winiarska@xxxxxxxxx>
> Cc: Guenter Roeck <linux@xxxxxxxxxxxx>
> Cc: linux-hwmon@xxxxxxxxxxxxxxx
> Cc: openbmc@xxxxxxxxxxxxxxxx
> Cc: Tony Luck <tony.luck@xxxxxxxxx>
> Cc: x86@xxxxxxxxxx
> Cc: Thomas Gleixner <tglx@xxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Borislav Petkov <bp@xxxxxxxxx>
> Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
> 

For v3, feel free to add

Reviewed-by: Iwona Winiarska <iwona.winiarska@xxxxxxxxx>

Thanks
-Iwona