| Message ID | 20241220213711.1892696-9-sohil.mehta@intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Prepare for new Intel family models | expand |
On Fri, 20 Dec 2024 21:37:03 +0000 Sohil Mehta <sohil.mehta@intel.com> wrote: > Introduce names for some old pentium models and replace with VFM based > checks. > > Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> > --- > arch/x86/include/asm/intel-family.h | 3 +++ > arch/x86/kernel/cpu/intel.c | 13 ++++++------- > 2 files changed, 9 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h > index 6d7b04ffc5fd..41278093bcd4 100644 > --- a/arch/x86/include/asm/intel-family.h > +++ b/arch/x86/include/asm/intel-family.h > @@ -46,6 +46,9 @@ > #define INTEL_ANY IFM(X86_FAMILY_ANY, X86_MODEL_ANY) > > #define INTEL_PENTIUM_PRO IFM(6, 0x01) > +#define INTEL_PENTIUM_II_KLAMATH IFM(6, 0x03) > +#define INTEL_PENTIUM_III_TUALATIN IFM(6, 0x0B) > +#define INTEL_PENTIUM_M_DOTHAN IFM(6, 0x0D) > > #define INTEL_CORE_YONAH IFM(6, 0x0E) I think I'd add all the extra defines in one patch. Isn't the order 'funny' as well. I think it ends up being neither numeric or date order. Increasing family order is probably best, but the headings for each 'family' probably need to be a bit more descriptive (esp 15 - all P4 netburst). David
On 12/21/24 02:35, David Laight wrote: >> #define INTEL_PENTIUM_PRO IFM(6, 0x01) >> +#define INTEL_PENTIUM_II_KLAMATH IFM(6, 0x03) >> +#define INTEL_PENTIUM_III_TUALATIN IFM(6, 0x0B) >> +#define INTEL_PENTIUM_M_DOTHAN IFM(6, 0x0D) >> >> #define INTEL_CORE_YONAH IFM(6, 0x0E) > > I think I'd add all the extra defines in one patch. I actually prefer them being with their first user. That way, if patches get dropped or moved, nothing can be in the wrong order or unnecessary. > Isn't the order 'funny' as well. > I think it ends up being neither numeric or date order. > Increasing family order is probably best, but the headings for each > 'family' probably need to be a bit more descriptive (esp 15 - all P4 > netburst). <shrug> They're already out of order because Quark is a weirdo and we didn't want to look at it all the time so it got stuck at the bottom. It's _fine_ when it's 99% family 6 plus 2 other weirdos. But it should probably get sorted at some point because it's going to be hard to find Quark and P4 if the order is fam 6,1 fam 5 fam 15 fam 18 fam 19 fam 20 ... But I think all that has to be done is to move Quark up to the top.
On Sat, 21 Dec 2024 07:57:10 -0800 Dave Hansen <dave.hansen@intel.com> wrote: > On 12/21/24 02:35, David Laight wrote: > >> #define INTEL_PENTIUM_PRO IFM(6, 0x01) > >> +#define INTEL_PENTIUM_II_KLAMATH IFM(6, 0x03) > >> +#define INTEL_PENTIUM_III_TUALATIN IFM(6, 0x0B) > >> +#define INTEL_PENTIUM_M_DOTHAN IFM(6, 0x0D) > >> > >> #define INTEL_CORE_YONAH IFM(6, 0x0E) > > > > I think I'd add all the extra defines in one patch. > > I actually prefer them being with their first user. That way, if patches > get dropped or moved, nothing can be in the wrong order or unnecessary. Does 'unnecessary' matter. It isn't as though there are hundreds of them. David
On 12/21/24 08:48, David Laight wrote: > On Sat, 21 Dec 2024 07:57:10 -0800 > Dave Hansen <dave.hansen@intel.com> wrote: > >> On 12/21/24 02:35, David Laight wrote: >>>> #define INTEL_PENTIUM_PRO IFM(6, 0x01) >>>> +#define INTEL_PENTIUM_II_KLAMATH IFM(6, 0x03) >>>> +#define INTEL_PENTIUM_III_TUALATIN IFM(6, 0x0B) >>>> +#define INTEL_PENTIUM_M_DOTHAN IFM(6, 0x0D) >>>> >>>> #define INTEL_CORE_YONAH IFM(6, 0x0E) >>> I think I'd add all the extra defines in one patch. >> I actually prefer them being with their first user. That way, if patches >> get dropped or moved, nothing can be in the wrong order or unnecessary. > Does 'unnecessary' matter. > It isn't as though there are hundreds of them. It matters to me. I'll let Sohil make the decision if he want to follow your preferences or mine.
On 12/21/2024 7:57 AM, Dave Hansen wrote: >> Isn't the order 'funny' as well. >> I think it ends up being neither numeric or date order. >> Increasing family order is probably best, but the headings for each >> 'family' probably need to be a bit more descriptive (esp 15 - all P4 >> netburst). > > <shrug> > > They're already out of order because Quark is a weirdo and we didn't > want to look at it all the time so it got stuck at the bottom. It's > _fine_ when it's 99% family 6 plus 2 other weirdos. > > But it should probably get sorted at some point because it's going to be > hard to find Quark and P4 if the order is > > fam 6,1 > fam 5 > fam 15 > fam 18 > fam 19 > fam 20 > ... > > But I think all that has to be done is to move Quark up to the top. > Patch 10/15 adds a few Family 5 defines. I'll move Family 5 to the top along with that.
diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 6d7b04ffc5fd..41278093bcd4 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -46,6 +46,9 @@ #define INTEL_ANY IFM(X86_FAMILY_ANY, X86_MODEL_ANY) #define INTEL_PENTIUM_PRO IFM(6, 0x01) +#define INTEL_PENTIUM_II_KLAMATH IFM(6, 0x03) +#define INTEL_PENTIUM_III_TUALATIN IFM(6, 0x0B) +#define INTEL_PENTIUM_M_DOTHAN IFM(6, 0x0D) #define INTEL_CORE_YONAH IFM(6, 0x0E) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index f44b2e618fb3..cde8f45ccd57 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -195,7 +195,7 @@ void intel_unlock_cpuid_leafs(struct cpuinfo_x86 *c) if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) return; - if (c->x86 < 6 || (c->x86 == 6 && c->x86_model < 0xd)) + if (c->x86_vfm < INTEL_PENTIUM_M_DOTHAN) return; /* @@ -301,7 +301,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) * If fast string is not enabled in IA32_MISC_ENABLE for any reason, * clear the fast string and enhanced fast string CPU capabilities. */ - if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) { + if (c->x86_vfm >= INTEL_PENTIUM_M_DOTHAN) { rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING)) { pr_info("Disabled fast string operations\n"); @@ -350,9 +350,7 @@ static void bsp_init_intel(struct cpuinfo_x86 *c) int ppro_with_ram_bug(void) { /* Uses data from early_cpu_detect now */ - if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && - boot_cpu_data.x86 == 6 && - boot_cpu_data.x86_model == 1 && + if (boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO && boot_cpu_data.x86_stepping < 8) { pr_info("Pentium Pro with Errata#50 detected. Taking evasive action.\n"); return 1; @@ -413,7 +411,8 @@ static void intel_workarounds(struct cpuinfo_x86 *c) * SEP CPUID bug: Pentium Pro reports SEP but doesn't have it until * model 3 mask 3 */ - if ((c->x86<<8 | c->x86_model<<4 | c->x86_stepping) < 0x633) + if ((c->x86_vfm == INTEL_PENTIUM_II_KLAMATH && c->x86_stepping < 3) || + c->x86_vfm < INTEL_PENTIUM_II_KLAMATH) clear_cpu_cap(c, X86_FEATURE_SEP); /* @@ -620,7 +619,7 @@ static unsigned int intel_size_cache(struct cpuinfo_x86 *c, unsigned int size) * to determine which, so we use a boottime override * for the 512kb model, and assume 256 otherwise. */ - if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0)) + if (c->x86_vfm == INTEL_PENTIUM_III_TUALATIN && size == 0) size = 256; /*
Introduce names for some old pentium models and replace with VFM based checks. Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> --- arch/x86/include/asm/intel-family.h | 3 +++ arch/x86/kernel/cpu/intel.c | 13 ++++++------- 2 files changed, 9 insertions(+), 7 deletions(-)