[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DS7PR11MB6077A36D7BC6832E3ACEA1B2FC63A@DS7PR11MB6077.namprd11.prod.outlook.com>
Date: Wed, 11 Feb 2026 22:21:47 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "Mehta, Sohil"
<sohil.mehta@...el.com>
CC: Dave Hansen <dave.hansen@...ux.intel.com>, "Liu, Zhao1"
<zhao1.liu@...el.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"
<hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, "Kohler, Jon"
<jon@...anix.com>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, "Peter
Zijlstra (Intel)" <peterz@...radead.org>, Thomas Gleixner <tglx@...nel.org>,
"x86@...nel.org" <x86@...nel.org>, "Winiarska, Iwona"
<iwona.winiarska@...el.com>, LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into
separate header
> But we basically never care about the format that's in CPUID.01H:EAX.
> The PECI code has none of that. It's *just* matching the "id" of the
> device to the "id" of the CPU. It just so happens that the "id" that's
> chosen matches CPUID.01H:EAX.
> So PECI and x86 both want the same data, but they do very different
> things with it.
> So let's just duplicate the constants. Completely untested patch attached.
> Any reason not to do this?
PECI code doesn't care about the stepping. You drop it when initializing
the device_id:
+ device->info.device_id = cpu_id >> 4;
But then you defined all the PECI model constants with the stepping.
E.g.
+#define PECI_INTEL_HASWELL_X 0x306C0
Perhaps drop the trailing '0' nibble and add a comment about the ID
being stepping independent?
-Tony
Powered by blists - more mailing lists