Message ID | 20210803113134.2262882-2-iwona.winiarska@intel.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | Introduce PECI subsystem | expand |
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...
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
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.
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...
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
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
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.
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.
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. >
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 --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 */