lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 20 Mar 2020 23:52:42 +0200 From: Andy Shevchenko <andy.shevchenko@...il.com> To: Thomas Gleixner <tglx@...utronix.de> Cc: LKML <linux-kernel@...r.kernel.org>, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Mark Gross <mgross@...ux.intel.com>, Tony Luck <tony.luck@...el.com>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Viresh Kumar <viresh.kumar@...aro.org>, Linux PM <linux-pm@...r.kernel.org>, Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, Len Brown <lenb@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Darren Hart <dvhart@...radead.org>, Andy Shevchenko <andy@...radead.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, linux-edac@...r.kernel.org, Platform Driver <platform-driver-x86@...r.kernel.org>, Jean Delvare <jdelvare@...e.com>, Guenter Roeck <linux@...ck-us.net>, linux-hwmon@...r.kernel.org, Zhang Rui <rui.zhang@...el.com>, Daniel Lezcano <daniel.lezcano@...aro.org>, Amit Kucheria <amit.kucheria@...durent.com>, Chanwoo Choi <cw00.choi@...sung.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>, Adrian Hunter <adrian.hunter@...el.com>, Ulf Hansson <ulf.hansson@...aro.org>, linux-mmc <linux-mmc@...r.kernel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org, Takashi Iwai <tiwai@...e.com>, ALSA Development Mailing List <alsa-devel@...a-project.org>, Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, linux-crypto <linux-crypto@...r.kernel.org> Subject: Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros On Fri, Mar 20, 2020 at 10:30 PM Thomas Gleixner <tglx@...utronix.de> wrote: > > Andy Shevchenko <andy.shevchenko@...il.com> writes: > > On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@...utronix.de> wrote: > > > >> + X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, 9, X86_FEATURE_EST, NULL), > >> + X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, 13, X86_FEATURE_EST, NULL), > >> + X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 15, 3, X86_FEATURE_EST, NULL), > >> + X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 15, 4, X86_FEATURE_EST, NULL), > > > >> + X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, 0x8, 0), > >> + X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, 0xb, 0), > >> + X86_MATCH_VENDOR_FAM_MODEL(INTEL, 15, 0x2, 0), > > > >> + X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, 0x8, 0), > >> + X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, 0xb, 0), > >> + X86_MATCH_VENDOR_FAM_MODEL(INTEL, 15, 0x2, 0), > > > > Perhaps use names instead of 6 and 15? > > Thought about that and did not come up with anyting useful. FAM6 vs. 6 > is not really any better Hmm... Do we have family 15 for Intel? Perhaps I missed something... Or is it for any family? -- With Best Regards, Andy Shevchenko
Powered by blists - more mailing lists