diff mbox series

[v2,01/15] x86/cpu: Move intel-family to arch-independent headers

Message ID 20210803113134.2262882-2-iwona.winiarska@intel.com (mailing list archive)
State New, archived
Headers show
Series Introduce PECI subsystem | expand

Commit Message

Winiarska, Iwona Aug. 3, 2021, 11:31 a.m. UTC 
Baseboard management controllers (BMC) often run Linux but are usually
implemented with non-X86 processors. They can use PECI to access package
config space (PCS) registers on the host CPU and since some information,
e.g. figuring out the core count, can be obtained using different
registers on different CPU generations, they need to decode the family
and model.

Move the data from arch/x86/include/asm/intel-family.h into a new file
include/linux/x86/intel-family.h so that it can be used by other
architectures.

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
---
To limit tree-wide changes and help people that were expecting
intel-family defines in arch/x86 to find it more easily without going
through git history, we're not removing the original header
completely, we're keeping it as a "stub" that includes the new one.
If there is a consensus that the tree-wide option is better,
we can choose this approach.

 MAINTAINERS                         |   2 +
 arch/x86/include/asm/intel-family.h | 141 +--------------------------
 include/linux/x86/intel-family.h    | 146 ++++++++++++++++++++++++++++
 3 files changed, 149 insertions(+), 140 deletions(-)
 create mode 100644 include/linux/x86/intel-family.h

Comments

Borislav Petkov Oct. 4, 2021, 7:03 p.m. UTC | #1 
On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
> Baseboard management controllers (BMC) often run Linux but are usually
> implemented with non-X86 processors. They can use PECI to access package
> config space (PCS) registers on the host CPU and since some information,
> e.g. figuring out the core count, can be obtained using different
> registers on different CPU generations, they need to decode the family
> and model.
> 
> Move the data from arch/x86/include/asm/intel-family.h into a new file
> include/linux/x86/intel-family.h so that it can be used by other
> architectures.
> 
> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> ---
> To limit tree-wide changes and help people that were expecting
> intel-family defines in arch/x86 to find it more easily without going
> through git history, we're not removing the original header
> completely, we're keeping it as a "stub" that includes the new one.
> If there is a consensus that the tree-wide option is better,
> we can choose this approach.

Why can't the linux/ namespace header include the x86 one so that
nothing changes for arch/x86/?

And if it is really only a handful of families you need, you might just
as well copy them into the peci headers and slap a comment above it
saying where they come from and save yourself all that churn...
Winiarska, Iwona Oct. 11, 2021, 7:21 p.m. UTC | #2 
On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:
> On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
> > Baseboard management controllers (BMC) often run Linux but are usually
> > implemented with non-X86 processors. They can use PECI to access package
> > config space (PCS) registers on the host CPU and since some information,
> > e.g. figuring out the core count, can be obtained using different
> > registers on different CPU generations, they need to decode the family
> > and model.
> > 
> > Move the data from arch/x86/include/asm/intel-family.h into a new file
> > include/linux/x86/intel-family.h so that it can be used by other
> > architectures.
> > 
> > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> > Reviewed-by: Tony Luck <tony.luck@intel.com>
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> > To limit tree-wide changes and help people that were expecting
> > intel-family defines in arch/x86 to find it more easily without going
> > through git history, we're not removing the original header
> > completely, we're keeping it as a "stub" that includes the new one.
> > If there is a consensus that the tree-wide option is better,
> > we can choose this approach.
> 
> Why can't the linux/ namespace header include the x86 one so that
> nothing changes for arch/x86/?

Same reason why PECI can't just include arch/x86 directly (we're building for
ARM, not x86).

> And if it is really only a handful of families you need, you might just
> as well copy them into the peci headers and slap a comment above it
> saying where they come from and save yourself all that churn...

It's a handful of families for now - but I do expect the list to grow once new
platforms are introduced (and with that - duplicates have to be added in both
places).

Since the churn is relatively low I wanted to start with trying to keep things
clean first.
If you're against that - sure, we can duplicate. 

Thanks
-Iwona
Dave Hansen Oct. 11, 2021, 7:40 p.m. UTC | #3 
On 10/11/21 12:21 PM, Winiarska, Iwona wrote:
> On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:
>> On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
>>> Baseboard management controllers (BMC) often run Linux but are usually
>>> implemented with non-X86 processors. They can use PECI to access package
>>> config space (PCS) registers on the host CPU and since some information,
>>> e.g. figuring out the core count, can be obtained using different
>>> registers on different CPU generations, they need to decode the family
>>> and model.
>>>
>>> Move the data from arch/x86/include/asm/intel-family.h into a new file
>>> include/linux/x86/intel-family.h so that it can be used by other
>>> architectures.
>>>
>>> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
>>> Reviewed-by: Tony Luck <tony.luck@intel.com>
>>> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
>>> ---
>>> To limit tree-wide changes and help people that were expecting
>>> intel-family defines in arch/x86 to find it more easily without going
>>> through git history, we're not removing the original header
>>> completely, we're keeping it as a "stub" that includes the new one.
>>> If there is a consensus that the tree-wide option is better,
>>> we can choose this approach.
>> Why can't the linux/ namespace header include the x86 one so that
>> nothing changes for arch/x86/?
> Same reason why PECI can't just include arch/x86 directly (we're building for
> ARM, not x86).
If you're in include/linux/x86-hacks.h, what prevents you from doing

#include "../../arch/x86/include/asm/intel-family.h"

?

In the end, to the compiler, it's just a file in a weird location in the
tree.  I think I'd prefer one weird include to moving that file out of
arch/x86.
Borislav Petkov Oct. 11, 2021, 8:06 p.m. UTC | #4 
On Mon, Oct 11, 2021 at 07:21:26PM +0000, Winiarska, Iwona wrote:
> Same reason why PECI can't just include arch/x86 directly (we're building for
> ARM, not x86).

Aha.

So what do you need those INTEL_FAM6* defines for?

I see peci_cpu_device_ids[] which are used to match the CPU so at least
that thing must be loading on x86 hardware... reading your 0th message,
it sounds like that peci-cpu thing is loaded on an x86 CPU and it then
exposes those interfaces which a PECI controller accesses.

And then I see in init_core_mask() the single usage of INTEL_FAM6* and
that drivers/hwmon/peci/cputemp.c is a CPU temp monitoring client so
that thing probably runs on x86 too.

Or?

If it does, then you don't need the code move.

But it looks like I'm missing something...
Winiarska, Iwona Oct. 11, 2021, 8:38 p.m. UTC | #5 
On Mon, 2021-10-11 at 22:06 +0200, Borislav Petkov wrote:
> On Mon, Oct 11, 2021 at 07:21:26PM +0000, Winiarska, Iwona wrote:
> > Same reason why PECI can't just include arch/x86 directly (we're building
> > for
> > ARM, not x86).
> 
> Aha.
> 
> So what do you need those INTEL_FAM6* defines for?

To identify the x86 CPU and use that as a match for binding PECI drivers.

> I see peci_cpu_device_ids[] which are used to match the CPU so at least
> that thing must be loading on x86 hardware... reading your 0th message,
> it sounds like that peci-cpu thing is loaded on an x86 CPU and it then
> exposes those interfaces which a PECI controller accesses.

Everything that's part of this series runs on the BMC (Baseboard Management
Controller). There's nothing ARM specific to it - it's just that the BMC
hardware we're currently supporting is ARM-based.
PECI is an interface that's exposed by some x86 CPUs - but that's a hardware
interface (available completely independent from whatever is actually running on
the x86 CPU).

> 
> And then I see in init_core_mask() the single usage of INTEL_FAM6* and
> that drivers/hwmon/peci/cputemp.c is a CPU temp monitoring client so
> that thing probably runs on x86 too.

That also runs on BMC, it uses functionality offered by peci-cpu to expose hwmon
interface to userspace.
Userspace that makes use of that hwmon interface also runs on the BMC and
exposes sensor data to user (via redfish API, or web-based interface).

> Or?
> 
> If it does, then you don't need the code move.
> 
> But it looks like I'm missing something...
> 

I'm sorry - it looks that my description in the cover letter wasn't clear
enough.

Thanks
-Iwona
Winiarska, Iwona Oct. 11, 2021, 8:53 p.m. UTC | #6 
On Mon, 2021-10-11 at 12:40 -0700, Dave Hansen wrote:
> On 10/11/21 12:21 PM, Winiarska, Iwona wrote:
> > On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:
> > > On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
> > > > Baseboard management controllers (BMC) often run Linux but are usually
> > > > implemented with non-X86 processors. They can use PECI to access package
> > > > config space (PCS) registers on the host CPU and since some information,
> > > > e.g. figuring out the core count, can be obtained using different
> > > > registers on different CPU generations, they need to decode the family
> > > > and model.
> > > > 
> > > > Move the data from arch/x86/include/asm/intel-family.h into a new file
> > > > include/linux/x86/intel-family.h so that it can be used by other
> > > > architectures.
> > > > 
> > > > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> > > > Reviewed-by: Tony Luck <tony.luck@intel.com>
> > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > ---
> > > > To limit tree-wide changes and help people that were expecting
> > > > intel-family defines in arch/x86 to find it more easily without going
> > > > through git history, we're not removing the original header
> > > > completely, we're keeping it as a "stub" that includes the new one.
> > > > If there is a consensus that the tree-wide option is better,
> > > > we can choose this approach.
> > > Why can't the linux/ namespace header include the x86 one so that
> > > nothing changes for arch/x86/?
> > Same reason why PECI can't just include arch/x86 directly (we're building
> > for
> > ARM, not x86).
> If you're in include/linux/x86-hacks.h, what prevents you from doing
> 
> #include "../../arch/x86/include/asm/intel-family.h"
> 
> ?
> 
> In the end, to the compiler, it's just a file in a weird location in the
> tree.  I think I'd prefer one weird include to moving that file out of
> arch/x86.

Using relative includes in include/linux is uncommon (I can see just one usage
in libfdt.h pulling stuff from scripts), so I thought I can't use it in this way
(seems slightly hacky to pull stuff from outside include path).

But if that would be ok, it looks like a good alternative to avoid duplication
in this case.

Thanks
-Iwona
Borislav Petkov Oct. 11, 2021, 9:31 p.m. UTC | #7 
On Mon, Oct 11, 2021 at 08:38:43PM +0000, Winiarska, Iwona wrote:
> Everything that's part of this series runs on the BMC (Baseboard
> Management Controller). There's nothing ARM specific to it - it's just
> that the BMC hardware we're currently supporting is ARM-based. PECI is
> an interface that's exposed by some x86 CPUs - but that's a hardware
> interface (available completely independent from whatever is actually
> running on the x86 CPU).

Aha, I think I got it: so this whole PECI pile is supposed to run on
the BMC - which can be ARM but doesn't have to be, i.e., code should be
generic enough - and the interfaces to the x86 CPU do get exposed to the
Linux running on the BMC.

Which brings me to the answer to your other mail:

On Mon, Oct 11, 2021 at 07:32:38PM +0000, Winiarska, Iwona wrote:
> Nothing wrong - just a trade-off between churn and keeping things tidy
> and not duplicated, similar to patch 1. And just like in patch 1, if
> you have a strong opinion against it - we can duplicate.

So it is not about strong opinion. Rather, it is about whether this
exporting would be disadvantageous for x86 freedom. And I think it will
be:

Because if you exported those and then we went and changed those
interfaces and defines (changed their naming, function arguments,
whatever) and something outside of x86 used them, we will break that
something.

And usually we go and fix those users too but I doubt anyone has access
to that PECI hw to actually test fixes, etc, etc.

So I'd prefer the small amount of duplication vs external stuff using
x86 facilities any day of the week. And so I'd suggest you simply copy
the handful of functions and defines you're gonna be needing and the
defines and be done with it.

Dave's idea makes sense to me too but lately it keeps happening that
we change something in x86-land and it turns out something "from the
outside" is using it and it breaks, so it is a lot easier if things are
independent.

Thx.
Dave Hansen Oct. 11, 2021, 11:12 p.m. UTC | #8 
On 10/11/21 1:53 PM, Winiarska, Iwona wrote:
>> If you're in include/linux/x86-hacks.h, what prevents you from doing
>>
>> #include "../../arch/x86/include/asm/intel-family.h"
>>
>> ?
>>
>> In the end, to the compiler, it's just a file in a weird location in the
>> tree.  I think I'd prefer one weird include to moving that file out of
>> arch/x86.
> Using relative includes in include/linux is uncommon (I can see just one usage
> in libfdt.h pulling stuff from scripts), so I thought I can't use it in this way
> (seems slightly hacky to pull stuff from outside include path).
> 
> But if that would be ok, it looks like a good alternative to avoid duplication
> in this case.

If you don't want to do it from a header, you can also do it directly
from a .c file that's outside of arch/x86.

I think that's a much better alternative than moving stuff elsewhere.
Winiarska, Iwona Oct. 12, 2021, 11:15 p.m. UTC | #9 
On Mon, 2021-10-11 at 23:31 +0200, Borislav Petkov wrote:
> On Mon, Oct 11, 2021 at 08:38:43PM +0000, Winiarska, Iwona wrote:
> > Everything that's part of this series runs on the BMC (Baseboard
> > Management Controller). There's nothing ARM specific to it - it's just
> > that the BMC hardware we're currently supporting is ARM-based. PECI is
> > an interface that's exposed by some x86 CPUs - but that's a hardware
> > interface (available completely independent from whatever is actually
> > running on the x86 CPU).
> 
> Aha, I think I got it: so this whole PECI pile is supposed to run on
> the BMC - which can be ARM but doesn't have to be, i.e., code should be
> generic enough - and the interfaces to the x86 CPU do get exposed to the
> Linux running on the BMC.
> 
> Which brings me to the answer to your other mail:
> 
> On Mon, Oct 11, 2021 at 07:32:38PM +0000, Winiarska, Iwona wrote:
> > Nothing wrong - just a trade-off between churn and keeping things tidy
> > and not duplicated, similar to patch 1. And just like in patch 1, if
> > you have a strong opinion against it - we can duplicate.
> 
> So it is not about strong opinion. Rather, it is about whether this
> exporting would be disadvantageous for x86 freedom. And I think it will
> be:
> 
> Because if you exported those and then we went and changed those
> interfaces and defines (changed their naming, function arguments,
> whatever) and something outside of x86 used them, we will break that
> something.
> 
> And usually we go and fix those users too but I doubt anyone has access
> to that PECI hw to actually test fixes, etc, etc.

We (OpenBMC) do have PECI HW, so that shouldn't be a problem.

> So I'd prefer the small amount of duplication vs external stuff using
> x86 facilities any day of the week. And so I'd suggest you simply copy
> the handful of functions and defines you're gonna be needing and the
> defines and be done with it.
> 
> Dave's idea makes sense to me too but lately it keeps happening that
> we change something in x86-land and it turns out something "from the
> outside" is using it and it breaks, so it is a lot easier if things are
> independent.

Both CPUID.EAX=1 decoding and definitions in intel-family are pretty "well-
defined". I understand the scenario that you're describing, but in order to
break the outside user there would need to be some "logic" behind the pulled in
concepts (if, for example, I would use something like X86_MATCH_* defines in
PECI).

Thanks
-Iwona

> 
> Thx.
>
Borislav Petkov Oct. 13, 2021, 6:42 a.m. UTC | #10 
On Tue, Oct 12, 2021 at 11:15:00PM +0000, Winiarska, Iwona wrote:
> We (OpenBMC) do have PECI HW, so that shouldn't be a problem.

Yeah, don't take it personally, but asking people to test stuff for you
doesn't really work, in practice.

> Both CPUID.EAX=1 decoding and definitions in intel-family are pretty "well-
> defined".

Sure, they are "well-defined" until we change them for whatever reason.
Then they will be "well-defined" again. But different.
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index c9467d2839f5..104773d40952 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9241,6 +9241,7 @@  M:	x86@kernel.org
 L:	linux-kernel@vger.kernel.org
 S:	Supported
 F:	arch/x86/include/asm/intel-family.h
+F:	include/linux/x86/intel-family.h
 
 INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
 M:	Jani Nikula <jani.nikula@linux.intel.com>
@@ -20105,6 +20106,7 @@  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
 F:	Documentation/devicetree/bindings/x86/
 F:	Documentation/x86/
 F:	arch/x86/
+F:	include/linux/x86/
 
 X86 ENTRY CODE
 M:	Andy Lutomirski <luto@kernel.org>
diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 27158436f322..0d4fe1b4e1f6 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -2,145 +2,6 @@ 
 #ifndef _ASM_X86_INTEL_FAMILY_H
 #define _ASM_X86_INTEL_FAMILY_H
 
-/*
- * "Big Core" Processors (Branded as Core, Xeon, etc...)
- *
- * While adding a new CPUID for a new microarchitecture, add a new
- * group to keep logically sorted out in chronological order. Within
- * that group keep the CPUID for the variants sorted by model number.
- *
- * The defined symbol names have the following form:
- *	INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
- * where:
- * OPTFAMILY	Describes the family of CPUs that this belongs to. Default
- *		is assumed to be "_CORE" (and should be omitted). Other values
- *		currently in use are _ATOM and _XEON_PHI
- * MICROARCH	Is the code name for the micro-architecture for this core.
- *		N.B. Not the platform name.
- * OPTDIFF	If needed, a short string to differentiate by market segment.
- *
- *		Common OPTDIFFs:
- *
- *			- regular client parts
- *		_L	- regular mobile parts
- *		_G	- parts with extra graphics on
- *		_X	- regular server parts
- *		_D	- micro server parts
- *
- *		Historical OPTDIFFs:
- *
- *		_EP	- 2 socket server parts
- *		_EX	- 4+ socket server parts
- *
- * The #define line may optionally include a comment including platform or core
- * names. An exception is made for skylake/kabylake where steppings seem to have gotten
- * their own names :-(
- */
-
-/* Wildcard match for FAM6 so X86_MATCH_INTEL_FAM6_MODEL(ANY) works */
-#define INTEL_FAM6_ANY			X86_MODEL_ANY
-
-#define INTEL_FAM6_CORE_YONAH		0x0E
-
-#define INTEL_FAM6_CORE2_MEROM		0x0F
-#define INTEL_FAM6_CORE2_MEROM_L	0x16
-#define INTEL_FAM6_CORE2_PENRYN		0x17
-#define INTEL_FAM6_CORE2_DUNNINGTON	0x1D
-
-#define INTEL_FAM6_NEHALEM		0x1E
-#define INTEL_FAM6_NEHALEM_G		0x1F /* Auburndale / Havendale */
-#define INTEL_FAM6_NEHALEM_EP		0x1A
-#define INTEL_FAM6_NEHALEM_EX		0x2E
-
-#define INTEL_FAM6_WESTMERE		0x25
-#define INTEL_FAM6_WESTMERE_EP		0x2C
-#define INTEL_FAM6_WESTMERE_EX		0x2F
-
-#define INTEL_FAM6_SANDYBRIDGE		0x2A
-#define INTEL_FAM6_SANDYBRIDGE_X	0x2D
-#define INTEL_FAM6_IVYBRIDGE		0x3A
-#define INTEL_FAM6_IVYBRIDGE_X		0x3E
-
-#define INTEL_FAM6_HASWELL		0x3C
-#define INTEL_FAM6_HASWELL_X		0x3F
-#define INTEL_FAM6_HASWELL_L		0x45
-#define INTEL_FAM6_HASWELL_G		0x46
-
-#define INTEL_FAM6_BROADWELL		0x3D
-#define INTEL_FAM6_BROADWELL_G		0x47
-#define INTEL_FAM6_BROADWELL_X		0x4F
-#define INTEL_FAM6_BROADWELL_D		0x56
-
-#define INTEL_FAM6_SKYLAKE_L		0x4E	/* Sky Lake             */
-#define INTEL_FAM6_SKYLAKE		0x5E	/* Sky Lake             */
-#define INTEL_FAM6_SKYLAKE_X		0x55	/* Sky Lake             */
-/*                 CASCADELAKE_X	0x55	   Sky Lake -- s: 7     */
-/*                 COOPERLAKE_X		0x55	   Sky Lake -- s: 11    */
-
-#define INTEL_FAM6_KABYLAKE_L		0x8E	/* Sky Lake             */
-/*                 AMBERLAKE_L		0x8E	   Sky Lake -- s: 9     */
-/*                 COFFEELAKE_L		0x8E	   Sky Lake -- s: 10    */
-/*                 WHISKEYLAKE_L	0x8E       Sky Lake -- s: 11,12 */
-
-#define INTEL_FAM6_KABYLAKE		0x9E	/* Sky Lake             */
-/*                 COFFEELAKE		0x9E	   Sky Lake -- s: 10-13 */
-
-#define INTEL_FAM6_COMETLAKE		0xA5	/* Sky Lake             */
-#define INTEL_FAM6_COMETLAKE_L		0xA6	/* Sky Lake             */
-
-#define INTEL_FAM6_CANNONLAKE_L		0x66	/* Palm Cove */
-
-#define INTEL_FAM6_ICELAKE_X		0x6A	/* Sunny Cove */
-#define INTEL_FAM6_ICELAKE_D		0x6C	/* Sunny Cove */
-#define INTEL_FAM6_ICELAKE		0x7D	/* Sunny Cove */
-#define INTEL_FAM6_ICELAKE_L		0x7E	/* Sunny Cove */
-#define INTEL_FAM6_ICELAKE_NNPI		0x9D	/* Sunny Cove */
-
-#define INTEL_FAM6_LAKEFIELD		0x8A	/* Sunny Cove / Tremont */
-
-#define INTEL_FAM6_ROCKETLAKE		0xA7	/* Cypress Cove */
-
-#define INTEL_FAM6_TIGERLAKE_L		0x8C	/* Willow Cove */
-#define INTEL_FAM6_TIGERLAKE		0x8D	/* Willow Cove */
-
-#define INTEL_FAM6_SAPPHIRERAPIDS_X	0x8F	/* Golden Cove */
-
-#define INTEL_FAM6_ALDERLAKE		0x97	/* Golden Cove / Gracemont */
-#define INTEL_FAM6_ALDERLAKE_L		0x9A	/* Golden Cove / Gracemont */
-
-/* "Small Core" Processors (Atom) */
-
-#define INTEL_FAM6_ATOM_BONNELL		0x1C /* Diamondville, Pineview */
-#define INTEL_FAM6_ATOM_BONNELL_MID	0x26 /* Silverthorne, Lincroft */
-
-#define INTEL_FAM6_ATOM_SALTWELL	0x36 /* Cedarview */
-#define INTEL_FAM6_ATOM_SALTWELL_MID	0x27 /* Penwell */
-#define INTEL_FAM6_ATOM_SALTWELL_TABLET	0x35 /* Cloverview */
-
-#define INTEL_FAM6_ATOM_SILVERMONT	0x37 /* Bay Trail, Valleyview */
-#define INTEL_FAM6_ATOM_SILVERMONT_D	0x4D /* Avaton, Rangely */
-#define INTEL_FAM6_ATOM_SILVERMONT_MID	0x4A /* Merriefield */
-
-#define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
-#define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
-#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
-
-#define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
-#define INTEL_FAM6_ATOM_GOLDMONT_D	0x5F /* Denverton */
-
-/* Note: the micro-architecture is "Goldmont Plus" */
-#define INTEL_FAM6_ATOM_GOLDMONT_PLUS	0x7A /* Gemini Lake */
-
-#define INTEL_FAM6_ATOM_TREMONT_D	0x86 /* Jacobsville */
-#define INTEL_FAM6_ATOM_TREMONT		0x96 /* Elkhart Lake */
-#define INTEL_FAM6_ATOM_TREMONT_L	0x9C /* Jasper Lake */
-
-/* Xeon Phi */
-
-#define INTEL_FAM6_XEON_PHI_KNL		0x57 /* Knights Landing */
-#define INTEL_FAM6_XEON_PHI_KNM		0x85 /* Knights Mill */
-
-/* Family 5 */
-#define INTEL_FAM5_QUARK_X1000		0x09 /* Quark X1000 SoC */
+#include <linux/x86/intel-family.h>
 
 #endif /* _ASM_X86_INTEL_FAMILY_H */
diff --git a/include/linux/x86/intel-family.h b/include/linux/x86/intel-family.h
new file mode 100644
index 000000000000..ae4b075c1ab9
--- /dev/null
+++ b/include/linux/x86/intel-family.h
@@ -0,0 +1,146 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_X86_INTEL_FAMILY_H
+#define _LINUX_X86_INTEL_FAMILY_H
+
+/*
+ * "Big Core" Processors (Branded as Core, Xeon, etc...)
+ *
+ * While adding a new CPUID for a new microarchitecture, add a new
+ * group to keep logically sorted out in chronological order. Within
+ * that group keep the CPUID for the variants sorted by model number.
+ *
+ * The defined symbol names have the following form:
+ *	INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
+ * where:
+ * OPTFAMILY	Describes the family of CPUs that this belongs to. Default
+ *		is assumed to be "_CORE" (and should be omitted). Other values
+ *		currently in use are _ATOM and _XEON_PHI
+ * MICROARCH	Is the code name for the micro-architecture for this core.
+ *		N.B. Not the platform name.
+ * OPTDIFF	If needed, a short string to differentiate by market segment.
+ *
+ *		Common OPTDIFFs:
+ *
+ *			- regular client parts
+ *		_L	- regular mobile parts
+ *		_G	- parts with extra graphics on
+ *		_X	- regular server parts
+ *		_D	- micro server parts
+ *
+ *		Historical OPTDIFFs:
+ *
+ *		_EP	- 2 socket server parts
+ *		_EX	- 4+ socket server parts
+ *
+ * The #define line may optionally include a comment including platform or core
+ * names. An exception is made for skylake/kabylake where steppings seem to have gotten
+ * their own names :-(
+ */
+
+/* Wildcard match for FAM6 so X86_MATCH_INTEL_FAM6_MODEL(ANY) works */
+#define INTEL_FAM6_ANY			X86_MODEL_ANY
+
+#define INTEL_FAM6_CORE_YONAH		0x0E
+
+#define INTEL_FAM6_CORE2_MEROM		0x0F
+#define INTEL_FAM6_CORE2_MEROM_L	0x16
+#define INTEL_FAM6_CORE2_PENRYN		0x17
+#define INTEL_FAM6_CORE2_DUNNINGTON	0x1D
+
+#define INTEL_FAM6_NEHALEM		0x1E
+#define INTEL_FAM6_NEHALEM_G		0x1F /* Auburndale / Havendale */
+#define INTEL_FAM6_NEHALEM_EP		0x1A
+#define INTEL_FAM6_NEHALEM_EX		0x2E
+
+#define INTEL_FAM6_WESTMERE		0x25
+#define INTEL_FAM6_WESTMERE_EP		0x2C
+#define INTEL_FAM6_WESTMERE_EX		0x2F
+
+#define INTEL_FAM6_SANDYBRIDGE		0x2A
+#define INTEL_FAM6_SANDYBRIDGE_X	0x2D
+#define INTEL_FAM6_IVYBRIDGE		0x3A
+#define INTEL_FAM6_IVYBRIDGE_X		0x3E
+
+#define INTEL_FAM6_HASWELL		0x3C
+#define INTEL_FAM6_HASWELL_X		0x3F
+#define INTEL_FAM6_HASWELL_L		0x45
+#define INTEL_FAM6_HASWELL_G		0x46
+
+#define INTEL_FAM6_BROADWELL		0x3D
+#define INTEL_FAM6_BROADWELL_G		0x47
+#define INTEL_FAM6_BROADWELL_X		0x4F
+#define INTEL_FAM6_BROADWELL_D		0x56
+
+#define INTEL_FAM6_SKYLAKE_L		0x4E	/* Sky Lake             */
+#define INTEL_FAM6_SKYLAKE		0x5E	/* Sky Lake             */
+#define INTEL_FAM6_SKYLAKE_X		0x55	/* Sky Lake             */
+/*                 CASCADELAKE_X	0x55	   Sky Lake -- s: 7     */
+/*                 COOPERLAKE_X		0x55	   Sky Lake -- s: 11    */
+
+#define INTEL_FAM6_KABYLAKE_L		0x8E	/* Sky Lake             */
+/*                 AMBERLAKE_L		0x8E	   Sky Lake -- s: 9     */
+/*                 COFFEELAKE_L		0x8E	   Sky Lake -- s: 10    */
+/*                 WHISKEYLAKE_L	0x8E       Sky Lake -- s: 11,12 */
+
+#define INTEL_FAM6_KABYLAKE		0x9E	/* Sky Lake             */
+/*                 COFFEELAKE		0x9E	   Sky Lake -- s: 10-13 */
+
+#define INTEL_FAM6_COMETLAKE		0xA5	/* Sky Lake             */
+#define INTEL_FAM6_COMETLAKE_L		0xA6	/* Sky Lake             */
+
+#define INTEL_FAM6_CANNONLAKE_L		0x66	/* Palm Cove */
+
+#define INTEL_FAM6_ICELAKE_X		0x6A	/* Sunny Cove */
+#define INTEL_FAM6_ICELAKE_D		0x6C	/* Sunny Cove */
+#define INTEL_FAM6_ICELAKE		0x7D	/* Sunny Cove */
+#define INTEL_FAM6_ICELAKE_L		0x7E	/* Sunny Cove */
+#define INTEL_FAM6_ICELAKE_NNPI		0x9D	/* Sunny Cove */
+
+#define INTEL_FAM6_LAKEFIELD		0x8A	/* Sunny Cove / Tremont */
+
+#define INTEL_FAM6_ROCKETLAKE		0xA7	/* Cypress Cove */
+
+#define INTEL_FAM6_TIGERLAKE_L		0x8C	/* Willow Cove */
+#define INTEL_FAM6_TIGERLAKE		0x8D	/* Willow Cove */
+
+#define INTEL_FAM6_SAPPHIRERAPIDS_X	0x8F	/* Golden Cove */
+
+#define INTEL_FAM6_ALDERLAKE		0x97	/* Golden Cove / Gracemont */
+#define INTEL_FAM6_ALDERLAKE_L		0x9A	/* Golden Cove / Gracemont */
+
+/* "Small Core" Processors (Atom) */
+
+#define INTEL_FAM6_ATOM_BONNELL		0x1C /* Diamondville, Pineview */
+#define INTEL_FAM6_ATOM_BONNELL_MID	0x26 /* Silverthorne, Lincroft */
+
+#define INTEL_FAM6_ATOM_SALTWELL	0x36 /* Cedarview */
+#define INTEL_FAM6_ATOM_SALTWELL_MID	0x27 /* Penwell */
+#define INTEL_FAM6_ATOM_SALTWELL_TABLET	0x35 /* Cloverview */
+
+#define INTEL_FAM6_ATOM_SILVERMONT	0x37 /* Bay Trail, Valleyview */
+#define INTEL_FAM6_ATOM_SILVERMONT_D	0x4D /* Avaton, Rangely */
+#define INTEL_FAM6_ATOM_SILVERMONT_MID	0x4A /* Merriefield */
+
+#define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
+#define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
+#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
+
+#define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
+#define INTEL_FAM6_ATOM_GOLDMONT_D	0x5F /* Denverton */
+
+/* Note: the micro-architecture is "Goldmont Plus" */
+#define INTEL_FAM6_ATOM_GOLDMONT_PLUS	0x7A /* Gemini Lake */
+
+#define INTEL_FAM6_ATOM_TREMONT_D	0x86 /* Jacobsville */
+#define INTEL_FAM6_ATOM_TREMONT		0x96 /* Elkhart Lake */
+#define INTEL_FAM6_ATOM_TREMONT_L	0x9C /* Jasper Lake */
+
+/* Xeon Phi */
+
+#define INTEL_FAM6_XEON_PHI_KNL		0x57 /* Knights Landing */
+#define INTEL_FAM6_XEON_PHI_KNM		0x85 /* Knights Mill */
+
+/* Family 5 */
+#define INTEL_FAM5_QUARK_X1000		0x09 /* Quark X1000 SoC */
+
+#endif /* _LINUX_X86_INTEL_FAMILY_H */