Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
* Re: [patch 02/22] x86/cpu: Add conistent CPU match macros
       [not found] ` <20200320131508.826011988@linutronix.de>
@ 2020-03-20 14:29   ` Bjorn Helgaas
  2020-03-20 14:39   ` Andy Shevchenko
  1 sibling, 0 replies; 26+ messages in thread
From: Bjorn Helgaas @ 2020-03-20 14:29 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, x86, Greg Kroah-Hartman, Mark Gross, Tony Luck,
	Paolo Bonzini, Darren Hart, Andy Shevchenko, Rafael J. Wysocki,
	Len Brown, linux-acpi, Viresh Kumar, linux-pm,
	Srinivas Pandruvada, linux-edac, platform-driver-x86,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, linux-pci, Takashi Iwai,
	alsa-devel, Herbert Xu, David S. Miller, linux-crypto

s/conistent/consistent/ in subject

On Fri, Mar 20, 2020 at 02:13:47PM +0100, Thomas Gleixner wrote:
> Finding all places which build x86_cpu_id match tables is tedious and the
> logic is hidden in lots of differently named macro wrappers.
> 
> Most of these initializer macros use plain C89 initializers which rely on
> the ordering of the struct members. So new members could only be added at
> the end of the struct, but that's ugly as hell and C99 initializers are
> really the right thing to use.
> 
> Provide a set of macros which:
> 
>   - Have a proper naming scheme, starting with X86_MATCH_
> 
>   - Use C99 initializers
> 
> The set of provided macros are all subsets of the base macro
> 
>     X86_MATCH_VENDOR_FAM_MODEL_FEATURE()
> 
> which allows to supply all possible selection criteria:
> 
>       vendor, family, model, feature
> 
> The other macros shorten this to avoid typing all arguments when they are
> not needed and would require one of the _ANY constants. They have been
> created due to the requirements of the existing usage sites.
> 
> Also a add a few model constants for Centaur CPUs and QUARK.

s/Also a/Also/

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 00/22] x86/treewide: Consolidate CPU match macro maze and get rid of C89 (sic!) initializers
       [not found] <20200320131345.635023594@linutronix.de>
@ 2020-03-20 14:31 ` Andy Shevchenko
       [not found] ` <20200320131508.736205164@linutronix.de>
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:31 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Paolo Bonzini,
	Darren Hart, Andy Shevchenko, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, linux-edac, Platform Driver, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

On Fri, Mar 20, 2020 at 3:19 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The x86 CPU matching based on struct x86_cpu_id:
>
>   - is using an inconsistent macro mess with pointlessly duplicated and
>     slightly different local macros. Finding the places is an art as there
>     is no consistent name space at all.
>
>   - is still mostly based on C89 struct initializers which rely on the
>     ordering of the struct members. That's proliferated forever as every
>     new driver just copies the mess from some exising one.
>
> A recent offlist conversation about adding more match criteria to the CPU
> matching logic instead of creating yet another set of horrors, reminded me
> of a pile of scripts and patches which I hacked on a few years ago when I
> tried to add something to struct x86_cpu_id.
>
> That stuff was finally not needed and ended up in my ever growing todo list
> and collected dust and cobwebs, but (un)surprisingly enough most of it
> still worked out of the box. The copy & paste machinery still works as it
> did years ago.
>
> There are a few places which needed extra care due to new creative macros,
> new check combinations etc. and surprisingly ONE open coded proper C99
> initializer.
>
> It was reasonably simple to make it at least compile and pass a quick
> binary equivalence check.
>
> The result is a X86_MATCH prefix based set of macros which are reflecting
> the needs of the usage sites and shorten the base macro which takes all
> possible parameters (vendor, family, model, feature, data) and uses proper
> C99 initializers.
>
> So extensions of the match logic are trivial after that.
>

Thank you, Thomas!

Briefly looking to the code, I like the idea. I'll do (minor) comments
on individual patches.

I see it incorporates my previous attempts to extend this, but now it
looks better.

> The patch set is against Linus tree and has trivial conflicts against
> linux-next.
>
> The diffstat is:
>  71 files changed, 525 insertions(+), 472 deletions(-)
>
> but the extra lines are pretty much kernel-doc documentation which I added
> to each of the new macros. The usage sites diffstat is:
>
>  70 files changed, 393 insertions(+), 471 deletions(-)
>
> Thoughts?
>
> Thanks,
>
>         tglx
>
>


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 01/22] x86/devicetable: Move x86 specific macro out of generic code
       [not found] ` <20200320131508.736205164@linutronix.de>
@ 2020-03-20 14:33   ` Andy Shevchenko
  2020-03-20 20:24     ` Thomas Gleixner
  0 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:33 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Paolo Bonzini,
	Darren Hart, Andy Shevchenko, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, linux-edac, Platform Driver, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

On Fri, Mar 20, 2020 at 3:17 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> There is no reason that this gunk is in a generic header file. The wildcard
> defines need to stay as they are required by file2alias.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  arch/x86/include/asm/cpu_device_id.h   |   13 ++++++++++++-
>  arch/x86/kvm/svm.c                     |    1 +
>  arch/x86/kvm/vmx/vmx.c                 |    1 +
>  drivers/cpufreq/acpi-cpufreq.c         |    1 +
>  drivers/cpufreq/amd_freq_sensitivity.c |    1 +
>  include/linux/mod_devicetable.h        |    4 +---
>  6 files changed, 17 insertions(+), 4 deletions(-)
>
> --- a/arch/x86/include/asm/cpu_device_id.h
> +++ b/arch/x86/include/asm/cpu_device_id.h
> @@ -6,10 +6,21 @@
>   * Declare drivers belonging to specific x86 CPUs
>   * Similar in spirit to pci_device_id and related PCI functions
>   */

> -

Seems you are going to remove below anyway in the next patches, so,
why not to do this also there?

>  #include <linux/mod_devicetable.h>

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 02/22] x86/cpu: Add conistent CPU match macros
       [not found] ` <20200320131508.826011988@linutronix.de>
  2020-03-20 14:29   ` [patch 02/22] x86/cpu: Add conistent CPU match macros Bjorn Helgaas
@ 2020-03-20 14:39   ` Andy Shevchenko
  2020-03-20 20:27     ` Thomas Gleixner
  1 sibling, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:39 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Paolo Bonzini,
	Darren Hart, Andy Shevchenko, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, linux-edac, Platform Driver, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Finding all places which build x86_cpu_id match tables is tedious and the
> logic is hidden in lots of differently named macro wrappers.
>
> Most of these initializer macros use plain C89 initializers which rely on
> the ordering of the struct members. So new members could only be added at
> the end of the struct, but that's ugly as hell and C99 initializers are
> really the right thing to use.
>
> Provide a set of macros which:
>
>   - Have a proper naming scheme, starting with X86_MATCH_
>
>   - Use C99 initializers
>
> The set of provided macros are all subsets of the base macro
>
>     X86_MATCH_VENDOR_FAM_MODEL_FEATURE()
>
> which allows to supply all possible selection criteria:
>
>       vendor, family, model, feature
>
> The other macros shorten this to avoid typing all arguments when they are
> not needed and would require one of the _ANY constants. They have been
> created due to the requirements of the existing usage sites.
>

> Also a add a few model constants for Centaur CPUs and QUARK.

I would perhaps made this as a separate change(s).

...

> +#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(_vendor, _family, _model,   \
> +                                          _feature, _data) {           \

I would leave it on one line despite the length, but it's up to you.

> +       .vendor         = X86_VENDOR_##_vendor,                         \
> +       .family         = _family,                                      \
> +       .model          = _model,                                       \
> +       .feature        = _feature,                                     \

> +       .driver_data    = (unsigned long) _data                         \

For sake of consistency shouldn't be this kernel_ulong_t ?
Or we are going to get rid of that type?

>  }

...

> +#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data)    \

> +       X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family,              \
> +                                          X86_MODEL_ANY, feature, data)

I would leave it on one line despite the length, but it's up to you.

...

> +#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data)                \
> +       X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model,       \
> +                                          X86_FEATURE_ANY, data)

Ditto.

...

> + * X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_BROADWELL,
> + *                                   X86_FEATURE_ANY, NULL);

Perhaps one line?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 08/22] ACPI: Convert to new X86 CPU match macros
       [not found] ` <20200320131509.467730627@linutronix.de>
@ 2020-03-20 14:47   ` " Andy Shevchenko
  2020-03-20 20:32     ` Thomas Gleixner
  0 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:47 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Len Brown, ACPI Devel Maling List, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, Viresh Kumar, Linux PM, Srinivas Pandruvada,
	linux-edac, Platform Driver, Jean Delvare, Guenter Roeck,
	linux-hwmon, Zhang Rui, Daniel Lezcano, Amit Kucheria,
	Chanwoo Choi, Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc,
	Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

On Fri, Mar 20, 2020 at 3:19 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The new macro set has a consistent namespace and uses C99 initializers
> instead of the grufty C89 ones.
>
> Rename the local macro wrapper to X86_MATCH for consistency. It stays for
> readability sake.

> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT,     NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT,        NULL),

> -#define ICPU(model)    { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> +#define X86_MATCH(model)       X86_MATCH_INTEL_FAM6_MODEL(model, NULL)

Maybe we can do a generic macro to avoid all these ', NULL' repetitions?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros
       [not found] ` <20200320131509.564059710@linutronix.de>
@ 2020-03-20 14:50   ` Andy Shevchenko
  2020-03-20 20:30     ` Thomas Gleixner
       [not found]   ` <20200324060124.GC11705@shao2-debian>
  2020-03-24 13:51   ` [patch V2 09/22] cpufreq: Convert to new X86 CPU match macros Thomas Gleixner
  2 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:50 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto

On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The new macro set has a consistent namespace and uses C99 initializers
> instead of the grufty C89 ones.
>
> Get rid the of most local macro wrappers for consistency. The ones which
> make sense for readability are renamed to X86_MATCH*.
>
> In the centrino driver this also removes the two extra duplicates of family
> 6 model 13 which have no value at all.

> +       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?
Also, NULL vs. 0?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 11/22] platform/x86: Convert to new CPU match macros
       [not found] ` <20200320131509.766573641@linutronix.de>
@ 2020-03-20 14:52   ` " Andy Shevchenko
  0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:52 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Darren Hart,
	Andy Shevchenko, Platform Driver, Paolo Bonzini,
	Rafael J. Wysocki, Len Brown, ACPI Devel Maling List,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, linux-edac,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto

On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The new macro set has a consistent namespace and uses C99 initializers
> instead of the grufty C89 ones.
>
> Get rid the of the local macro wrappers for consistency.
>

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Andy Shevchenko <andy@infradead.org>
> Cc: platform-driver-x86@vger.kernel.org
> ---
>  drivers/platform/x86/intel-uncore-frequency.c                 |   14 ++---
>  drivers/platform/x86/intel_int0002_vgpio.c                    |    4 -
>  drivers/platform/x86/intel_mid_powerbtn.c                     |    4 -
>  drivers/platform/x86/intel_pmc_core.c                         |   24 +++++-----
>  drivers/platform/x86/intel_pmc_core_pltdrv.c                  |   16 +++---
>  drivers/platform/x86/intel_speed_select_if/isst_if_mbox_msr.c |    4 -
>  drivers/platform/x86/intel_telemetry_debugfs.c                |    5 --
>  drivers/platform/x86/intel_telemetry_pltdrv.c                 |    7 --
>  drivers/platform/x86/intel_turbo_max_3.c                      |    6 --
>  9 files changed, 37 insertions(+), 47 deletions(-)
>
> --- a/drivers/platform/x86/intel-uncore-frequency.c
> +++ b/drivers/platform/x86/intel-uncore-frequency.c
> @@ -358,15 +358,13 @@ static struct notifier_block uncore_pm_n
>         .notifier_call = uncore_pm_notify,
>  };
>
> -#define ICPU(model)     { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> -
>  static const struct x86_cpu_id intel_uncore_cpu_ids[] = {
> -       ICPU(INTEL_FAM6_BROADWELL_G),
> -       ICPU(INTEL_FAM6_BROADWELL_X),
> -       ICPU(INTEL_FAM6_BROADWELL_D),
> -       ICPU(INTEL_FAM6_SKYLAKE_X),
> -       ICPU(INTEL_FAM6_ICELAKE_X),
> -       ICPU(INTEL_FAM6_ICELAKE_D),
> +       X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_G, NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_D, NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X,   NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_X,   NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_D,   NULL),
>         {}
>  };
>
> --- a/drivers/platform/x86/intel_int0002_vgpio.c
> +++ b/drivers/platform/x86/intel_int0002_vgpio.c
> @@ -148,8 +148,8 @@ static struct irq_chip int0002_cht_irqch
>  };
>
>  static const struct x86_cpu_id int0002_cpu_ids[] = {
> -       INTEL_CPU_FAM6(ATOM_SILVERMONT, int0002_byt_irqchip),   /* Valleyview, Bay Trail  */
> -       INTEL_CPU_FAM6(ATOM_AIRMONT, int0002_cht_irqchip),      /* Braswell, Cherry Trail */
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT,     &int0002_byt_irqchip),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT,        &int0002_cht_irqchip),
>         {}
>  };
>
> --- a/drivers/platform/x86/intel_mid_powerbtn.c
> +++ b/drivers/platform/x86/intel_mid_powerbtn.c
> @@ -113,8 +113,8 @@ static const struct mid_pb_ddata mrfld_d
>  };
>
>  static const struct x86_cpu_id mid_pb_cpu_ids[] = {
> -       INTEL_CPU_FAM6(ATOM_SALTWELL_MID,       mfld_ddata),
> -       INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,     mrfld_ddata),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_SALTWELL_MID,   &mfld_ddata),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT_MID, &mrfld_ddata),
>         {}
>  };
>
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -871,18 +871,18 @@ static inline void pmc_core_dbgfs_unregi
>  #endif /* CONFIG_DEBUG_FS */
>
>  static const struct x86_cpu_id intel_pmc_core_ids[] = {
> -       INTEL_CPU_FAM6(SKYLAKE_L, spt_reg_map),
> -       INTEL_CPU_FAM6(SKYLAKE, spt_reg_map),
> -       INTEL_CPU_FAM6(KABYLAKE_L, spt_reg_map),
> -       INTEL_CPU_FAM6(KABYLAKE, spt_reg_map),
> -       INTEL_CPU_FAM6(CANNONLAKE_L, cnp_reg_map),
> -       INTEL_CPU_FAM6(ICELAKE_L, icl_reg_map),
> -       INTEL_CPU_FAM6(ICELAKE_NNPI, icl_reg_map),
> -       INTEL_CPU_FAM6(COMETLAKE, cnp_reg_map),
> -       INTEL_CPU_FAM6(COMETLAKE_L, cnp_reg_map),
> -       INTEL_CPU_FAM6(TIGERLAKE_L, tgl_reg_map),
> -       INTEL_CPU_FAM6(TIGERLAKE, tgl_reg_map),
> -       INTEL_CPU_FAM6(ATOM_TREMONT, tgl_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_L,           &spt_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE,             &spt_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE_L,          &spt_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE,            &spt_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(CANNONLAKE_L,        &cnp_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_L,           &icl_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_NNPI,        &icl_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(COMETLAKE,           &cnp_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(COMETLAKE_L,         &cnp_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(TIGERLAKE_L,         &tgl_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(TIGERLAKE,           &tgl_reg_map),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_TREMONT,        &tgl_reg_map),
>         {}
>  };
>
> --- a/drivers/platform/x86/intel_pmc_core_pltdrv.c
> +++ b/drivers/platform/x86/intel_pmc_core_pltdrv.c
> @@ -38,14 +38,14 @@ static struct platform_device pmc_core_d
>   * other list may grow, but this list should not.
>   */
>  static const struct x86_cpu_id intel_pmc_core_platform_ids[] = {
> -       INTEL_CPU_FAM6(SKYLAKE_L, pmc_core_device),
> -       INTEL_CPU_FAM6(SKYLAKE, pmc_core_device),
> -       INTEL_CPU_FAM6(KABYLAKE_L, pmc_core_device),
> -       INTEL_CPU_FAM6(KABYLAKE, pmc_core_device),
> -       INTEL_CPU_FAM6(CANNONLAKE_L, pmc_core_device),
> -       INTEL_CPU_FAM6(ICELAKE_L, pmc_core_device),
> -       INTEL_CPU_FAM6(COMETLAKE, pmc_core_device),
> -       INTEL_CPU_FAM6(COMETLAKE_L, pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_L,           &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE,             &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE_L,          &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE,            &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(CANNONLAKE_L,        &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_L,           &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(COMETLAKE,           &pmc_core_device),
> +       X86_MATCH_INTEL_FAM6_MODEL(COMETLAKE_L,         &pmc_core_device),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, intel_pmc_core_platform_ids);
> --- a/drivers/platform/x86/intel_speed_select_if/isst_if_mbox_msr.c
> +++ b/drivers/platform/x86/intel_speed_select_if/isst_if_mbox_msr.c
> @@ -160,10 +160,8 @@ static struct notifier_block isst_pm_nb
>         .notifier_call = isst_pm_notify,
>  };
>
> -#define ICPU(model)     { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> -
>  static const struct x86_cpu_id isst_if_cpu_ids[] = {
> -       ICPU(INTEL_FAM6_SKYLAKE_X),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, isst_if_cpu_ids);
> --- a/drivers/platform/x86/intel_telemetry_debugfs.c
> +++ b/drivers/platform/x86/intel_telemetry_debugfs.c
> @@ -308,11 +308,10 @@ static struct telemetry_debugfs_conf tel
>  };
>
>  static const struct x86_cpu_id telemetry_debugfs_cpu_ids[] = {
> -       INTEL_CPU_FAM6(ATOM_GOLDMONT, telem_apl_debugfs_conf),
> -       INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, telem_apl_debugfs_conf),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT,       &telem_apl_debugfs_conf),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT_PLUS,  &telem_apl_debugfs_conf),
>         {}
>  };
> -
>  MODULE_DEVICE_TABLE(x86cpu, telemetry_debugfs_cpu_ids);
>
>  static int telemetry_debugfs_check_evts(void)
> --- a/drivers/platform/x86/intel_telemetry_pltdrv.c
> +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
> @@ -67,9 +67,6 @@
>  #define TELEM_CLEAR_VERBOSITY_BITS(x)  ((x) &= ~(BIT(27) | BIT(28)))
>  #define TELEM_SET_VERBOSITY_BITS(x, y) ((x) |= ((y) << 27))
>
> -#define TELEM_CPU(model, data) \
> -       { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&data }
> -
>  enum telemetry_action {
>         TELEM_UPDATE = 0,
>         TELEM_ADD,
> @@ -183,8 +180,8 @@ static struct telemetry_plt_config telem
>  };
>
>  static const struct x86_cpu_id telemetry_cpu_ids[] = {
> -       TELEM_CPU(INTEL_FAM6_ATOM_GOLDMONT, telem_apl_config),
> -       TELEM_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, telem_glk_config),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT,       &telem_apl_config),
> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT_PLUS,  &telem_glk_config),
>         {}
>  };
>
> --- a/drivers/platform/x86/intel_turbo_max_3.c
> +++ b/drivers/platform/x86/intel_turbo_max_3.c
> @@ -113,11 +113,9 @@ static int itmt_legacy_cpu_online(unsign
>         return 0;
>  }
>
> -#define ICPU(model)     { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> -
>  static const struct x86_cpu_id itmt_legacy_cpu_ids[] = {
> -       ICPU(INTEL_FAM6_BROADWELL_X),
> -       ICPU(INTEL_FAM6_SKYLAKE_X),
> +       X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, NULL),
> +       X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X,   NULL),
>         {}
>  };
>
>


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 19/22] ASoC: Intel: Convert to new X86 CPU match macros
       [not found] ` <20200320131510.594671507@linutronix.de>
@ 2020-03-20 14:58   ` " Andy Shevchenko
  0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 14:58 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Takashi Iwai,
	ALSA Development Mailing List, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, linux-edac, Platform Driver, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Herbert Xu,
	David S. Miller, linux-crypto

On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The new macro set has a consistent namespace and uses C99 initializers
> instead of the grufty C89 ones.
>
> Get rid the of the local macro wrappers for consistency.

> -#define ICPU(model)    { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> -
>  #define SOC_INTEL_IS_CPU(soc, type)                            \
>  static inline bool soc_intel_is_##soc(void)                    \
>  {                                                              \
>         static const struct x86_cpu_id soc##_cpu_ids[] = {      \
> -               ICPU(type),                                     \
> +               X86_MATCH_INTEL_FAM6_MODEL(type, NULL),         \
>                 {}                                              \
>         };                                                      \
>         const struct x86_cpu_id *id;                            \
> @@ -32,11 +30,11 @@ static inline bool soc_intel_is_##soc(vo
>         return false;                                           \
>  }
>

> +SOC_INTEL_IS_CPU(byt, ATOM_SILVERMONT);
> +SOC_INTEL_IS_CPU(cht, ATOM_AIRMONT);
> +SOC_INTEL_IS_CPU(apl, ATOM_GOLDMONT);
> +SOC_INTEL_IS_CPU(glk, ATOM_GOLDMONT_PLUS);
> +SOC_INTEL_IS_CPU(cml, KABYLAKE_L);

I'm wondering if driver data can be used in one macro to distinguish
which CPU we are run on.
Takashi, what do you think?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 00/22] x86/treewide: Consolidate CPU match macro maze and get rid of C89 (sic!) initializers
       [not found] <20200320131345.635023594@linutronix.de>
                   ` (5 preceding siblings ...)
       [not found] ` <20200320131510.594671507@linutronix.de>
@ 2020-03-20 14:59 ` Greg Kroah-Hartman
       [not found] ` <20200320131509.564059710@linutronix.de>
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2020-03-20 14:59 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, x86, Mark Gross, Tony Luck, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, Rafael J. Wysocki, Len Brown, linux-acpi,
	Viresh Kumar, linux-pm, Srinivas Pandruvada, linux-edac,
	platform-driver-x86, Jean Delvare, Guenter Roeck, linux-hwmon,
	Zhang Rui, Daniel Lezcano, Amit Kucheria, Chanwoo Choi,
	Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas,
	linux-pci, Takashi Iwai, alsa-devel, Herbert Xu, David S. Miller,
	linux-crypto

On Fri, Mar 20, 2020 at 02:13:45PM +0100, Thomas Gleixner wrote:
> The x86 CPU matching based on struct x86_cpu_id:
> 
>   - is using an inconsistent macro mess with pointlessly duplicated and
>     slightly different local macros. Finding the places is an art as there
>     is no consistent name space at all.
> 
>   - is still mostly based on C89 struct initializers which rely on the
>     ordering of the struct members. That's proliferated forever as every
>     new driver just copies the mess from some exising one.
> 
> A recent offlist conversation about adding more match criteria to the CPU
> matching logic instead of creating yet another set of horrors, reminded me
> of a pile of scripts and patches which I hacked on a few years ago when I
> tried to add something to struct x86_cpu_id.
> 
> That stuff was finally not needed and ended up in my ever growing todo list
> and collected dust and cobwebs, but (un)surprisingly enough most of it
> still worked out of the box. The copy & paste machinery still works as it
> did years ago.
> 
> There are a few places which needed extra care due to new creative macros,
> new check combinations etc. and surprisingly ONE open coded proper C99
> initializer.
> 
> It was reasonably simple to make it at least compile and pass a quick
> binary equivalence check.
> 
> The result is a X86_MATCH prefix based set of macros which are reflecting
> the needs of the usage sites and shorten the base macro which takes all
> possible parameters (vendor, family, model, feature, data) and uses proper
> C99 initializers.
> 
> So extensions of the match logic are trivial after that.
> 
> The patch set is against Linus tree and has trivial conflicts against
> linux-next.
> 
> The diffstat is:
>  71 files changed, 525 insertions(+), 472 deletions(-)
> 
> but the extra lines are pretty much kernel-doc documentation which I added
> to each of the new macros. The usage sites diffstat is:
> 
>  70 files changed, 393 insertions(+), 471 deletions(-)
> 
> Thoughts?

Much nicer looking, thanks for cleaning up this mess:

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 01/22] x86/devicetable: Move x86 specific macro out of generic code
  2020-03-20 14:33   ` [patch 01/22] x86/devicetable: Move x86 specific macro out of generic code Andy Shevchenko
@ 2020-03-20 20:24     ` Thomas Gleixner
  0 siblings, 0 replies; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-20 20:24 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Paolo Bonzini,
	Darren Hart, Andy Shevchenko, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, linux-edac, Platform Driver, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Fri, Mar 20, 2020 at 3:17 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> --- a/arch/x86/include/asm/cpu_device_id.h
>> +++ b/arch/x86/include/asm/cpu_device_id.h
>> @@ -6,10 +6,21 @@
>>   * Declare drivers belonging to specific x86 CPUs
>>   * Similar in spirit to pci_device_id and related PCI functions
>>   */
>
>> -
>
> Seems you are going to remove below anyway in the next patches, so,
> why not to do this also there?
>
>>  #include <linux/mod_devicetable.h>

No it stays, but yes I could do that comment change right here.

Thanks,

        tglx



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 02/22] x86/cpu: Add conistent CPU match macros
  2020-03-20 14:39   ` Andy Shevchenko
@ 2020-03-20 20:27     ` Thomas Gleixner
  0 siblings, 0 replies; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-20 20:27 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Paolo Bonzini,
	Darren Hart, Andy Shevchenko, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, linux-edac, Platform Driver, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>
>> Also a add a few model constants for Centaur CPUs and QUARK.
>
> I would perhaps made this as a separate change(s).

Can do.

>> +#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(_vendor, _family, _model,   \
>> +                                          _feature, _data) {           \
>
> I would leave it on one line despite the length, but it's up to you.
>
>> +       .vendor         = X86_VENDOR_##_vendor,                         \
>> +       .family         = _family,                                      \
>> +       .model          = _model,                                       \
>> +       .feature        = _feature,                                     \
>
>> +       .driver_data    = (unsigned long) _data                         \
>
> For sake of consistency shouldn't be this kernel_ulong_t ?

I can change that though in kernel space this does not matter.

> Or we are going to get rid of that type?

No.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros
  2020-03-20 14:50   ` [patch 09/22] cpufreq: Convert to new X86 CPU match macros Andy Shevchenko
@ 2020-03-20 20:30     ` Thomas Gleixner
  2020-03-20 21:52       ` Andy Shevchenko
  0 siblings, 1 reply; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-20 20:30 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto

Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.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

> Also, NULL vs. 0?

Both works, but yes I used mostly NULL.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 08/22] ACPI: Convert to new X86 CPU match macros
  2020-03-20 14:47   ` [patch 08/22] ACPI: Convert to new X86 " Andy Shevchenko
@ 2020-03-20 20:32     ` Thomas Gleixner
  2020-03-23 16:38       ` mark gross
  0 siblings, 1 reply; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-20 20:32 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Len Brown, ACPI Devel Maling List, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, Viresh Kumar, Linux PM, Srinivas Pandruvada,
	linux-edac, Platform Driver, Jean Delvare, Guenter Roeck,
	linux-hwmon, Zhang Rui, Daniel Lezcano, Amit Kucheria,
	Chanwoo Choi, Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc,
	Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Fri, Mar 20, 2020 at 3:19 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> The new macro set has a consistent namespace and uses C99 initializers
>> instead of the grufty C89 ones.
>>
>> Rename the local macro wrapper to X86_MATCH for consistency. It stays for
>> readability sake.
>
>> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT,     NULL),
>> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT,        NULL),
>
>> -#define ICPU(model)    { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
>> +#define X86_MATCH(model)       X86_MATCH_INTEL_FAM6_MODEL(model, NULL)
>
> Maybe we can do a generic macro to avoid all these ', NULL' repetitions?

I opted for having the data argument everywhere to keep the macro maze
small. And we have enough places where data is actually used.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros
  2020-03-20 20:30     ` Thomas Gleixner
@ 2020-03-20 21:52       ` Andy Shevchenko
  2020-03-20 22:18         ` Thomas Gleixner
  0 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-20 21:52 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto

On Fri, Mar 20, 2020 at 10:30 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> > On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros
  2020-03-20 21:52       ` Andy Shevchenko
@ 2020-03-20 22:18         ` Thomas Gleixner
  0 siblings, 0 replies; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-20 22:18 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Fri, Mar 20, 2020 at 10:30 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>> > On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@linutronix.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?

Pentium 4

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 08/22] ACPI: Convert to new X86 CPU match macros
  2020-03-20 20:32     ` Thomas Gleixner
@ 2020-03-23 16:38       ` mark gross
  0 siblings, 0 replies; 26+ messages in thread
From: mark gross @ 2020-03-23 16:38 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Andy Shevchenko, LKML,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Tony Luck, Rafael J. Wysocki, Len Brown,
	ACPI Devel Maling List, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, Viresh Kumar, Linux PM, Srinivas Pandruvada,
	linux-edac, Platform Driver, Jean Delvare, Guenter Roeck,
	linux-hwmon, Zhang Rui, Daniel Lezcano, Amit Kucheria,
	Chanwoo Choi, Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc,
	Bjorn Helgaas, linux-pci, Takashi Iwai,
	ALSA Development Mailing List, Herbert Xu, David S. Miller,
	linux-crypto

On Fri, Mar 20, 2020 at 09:32:26PM +0100, Thomas Gleixner wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> 
> > On Fri, Mar 20, 2020 at 3:19 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >>
> >> The new macro set has a consistent namespace and uses C99 initializers
> >> instead of the grufty C89 ones.
> >>
> >> Rename the local macro wrapper to X86_MATCH for consistency. It stays for
> >> readability sake.
> >
> >> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT,     NULL),
> >> +       X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT,        NULL),
> >
> >> -#define ICPU(model)    { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> >> +#define X86_MATCH(model)       X86_MATCH_INTEL_FAM6_MODEL(model, NULL)
> >
> > Maybe we can do a generic macro to avoid all these ', NULL' repetitions?
> 
> I opted for having the data argument everywhere to keep the macro maze
> small. And we have enough places where data is actually used.
+1

--mark

> Thanks,
> 
>         tglx

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression
       [not found]   ` <20200324060124.GC11705@shao2-debian>
@ 2020-03-24 10:24     ` Andy Shevchenko
  2020-03-24 15:38       ` Srinivas Pandruvada
  2020-03-25  7:50       ` Rong Chen
  0 siblings, 2 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-03-24 10:24 UTC (permalink / raw)
  To: kernel test robot
  Cc: Thomas Gleixner, LKML,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto, lkp

On Tue, Mar 24, 2020 at 8:02 AM kernel test robot <rong.a.chen@intel.com> wrote:
>
> Greeting,
>
> FYI, we noticed a -53.4% regression of will-it-scale.per_process_ops due to commit:

> commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22] cpufreq: Convert to new X86 CPU match macros")
> url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729
> base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next
>
> in testcase: will-it-scale
> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory
> with following parameters:


drivers/cpufreq/speedstep-centrino.c change missed the terminator,
perhaps it's a culprit, because I don't believe removing dups and
reordering lines may affect this.
Can you restore terminator there and re-test?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [patch V2 09/22] cpufreq: Convert to new X86 CPU match macros
       [not found] ` <20200320131509.564059710@linutronix.de>
  2020-03-20 14:50   ` [patch 09/22] cpufreq: Convert to new X86 CPU match macros Andy Shevchenko
       [not found]   ` <20200324060124.GC11705@shao2-debian>
@ 2020-03-24 13:51   ` Thomas Gleixner
  2020-03-24 15:37     ` Rafael J. Wysocki
  2 siblings, 1 reply; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-24 13:51 UTC (permalink / raw)
  To: LKML
  Cc: x86, Greg Kroah-Hartman, Mark Gross, Tony Luck,
	Rafael J. Wysocki, Viresh Kumar, linux-pm, Srinivas Pandruvada,
	Len Brown, Paolo Bonzini, Darren Hart, Andy Shevchenko,
	linux-acpi, linux-edac, platform-driver-x86, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	alsa-devel, Herbert Xu, David S. Miller, linux-crypto

The new macro set has a consistent namespace and uses C99 initializers
instead of the grufty C89 ones.

Get rid the of most local macro wrappers for consistency. The ones which
make sense for readability are renamed to X86_MATCH*.

In the centrino driver this also removes the two extra duplicates of family
6 model 13 which have no value at all.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
---
V2: Add the dropped terminator in the centrino speedstep driver back. (Andy)
---
 drivers/cpufreq/acpi-cpufreq.c         |    4 -
 drivers/cpufreq/amd_freq_sensitivity.c |    2 
 drivers/cpufreq/e_powersaver.c         |    2 
 drivers/cpufreq/elanfreq.c             |    2 
 drivers/cpufreq/intel_pstate.c         |   71 ++++++++++++++++-----------------
 drivers/cpufreq/longhaul.c             |    2 
 drivers/cpufreq/longrun.c              |    3 -
 drivers/cpufreq/p4-clockmod.c          |    2 
 drivers/cpufreq/powernow-k6.c          |    4 -
 drivers/cpufreq/powernow-k7.c          |    2 
 drivers/cpufreq/powernow-k8.c          |    2 
 drivers/cpufreq/sc520_freq.c           |    2 
 drivers/cpufreq/speedstep-centrino.c   |   14 +-----
 drivers/cpufreq/speedstep-ich.c        |   10 +---
 drivers/cpufreq/speedstep-smi.c        |   10 +---
 15 files changed, 59 insertions(+), 73 deletions(-)

--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -991,8 +991,8 @@ late_initcall(acpi_cpufreq_init);
 module_exit(acpi_cpufreq_exit);
 
 static const struct x86_cpu_id acpi_cpufreq_ids[] = {
-	X86_FEATURE_MATCH(X86_FEATURE_ACPI),
-	X86_FEATURE_MATCH(X86_FEATURE_HW_PSTATE),
+	X86_MATCH_FEATURE(X86_FEATURE_ACPI, NULL),
+	X86_MATCH_FEATURE(X86_FEATURE_HW_PSTATE, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, acpi_cpufreq_ids);
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -144,7 +144,7 @@ static void __exit amd_freq_sensitivity_
 module_exit(amd_freq_sensitivity_exit);
 
 static const struct x86_cpu_id amd_freq_sensitivity_ids[] = {
-	X86_FEATURE_MATCH(X86_FEATURE_PROC_FEEDBACK),
+	X86_MATCH_FEATURE(X86_FEATURE_PROC_FEEDBACK, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, amd_freq_sensitivity_ids);
--- a/drivers/cpufreq/e_powersaver.c
+++ b/drivers/cpufreq/e_powersaver.c
@@ -385,7 +385,7 @@ static struct cpufreq_driver eps_driver
 /* This driver will work only on Centaur C7 processors with
  * Enhanced SpeedStep/PowerSaver registers */
 static const struct x86_cpu_id eps_cpu_id[] = {
-	{ X86_VENDOR_CENTAUR, 6, X86_MODEL_ANY, X86_FEATURE_EST },
+	X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_EST, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, eps_cpu_id);
--- a/drivers/cpufreq/elanfreq.c
+++ b/drivers/cpufreq/elanfreq.c
@@ -198,7 +198,7 @@ static struct cpufreq_driver elanfreq_dr
 };
 
 static const struct x86_cpu_id elan_id[] = {
-	{ X86_VENDOR_AMD, 4, 10, },
+	X86_MATCH_VENDOR_FAM_MODEL(AMD, 4, 10, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, elan_id);
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1909,51 +1909,51 @@ static const struct pstate_funcs knl_fun
 	.get_val = core_get_val,
 };
 
-#define ICPU(model, policy) \
-	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_APERFMPERF,\
-			(unsigned long)&policy }
+#define X86_MATCH(model, policy)					 \
+	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
+					   X86_FEATURE_APERFMPERF, &policy)
 
 static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
-	ICPU(INTEL_FAM6_SANDYBRIDGE,		core_funcs),
-	ICPU(INTEL_FAM6_SANDYBRIDGE_X,		core_funcs),
-	ICPU(INTEL_FAM6_ATOM_SILVERMONT,	silvermont_funcs),
-	ICPU(INTEL_FAM6_IVYBRIDGE,		core_funcs),
-	ICPU(INTEL_FAM6_HASWELL,		core_funcs),
-	ICPU(INTEL_FAM6_BROADWELL,		core_funcs),
-	ICPU(INTEL_FAM6_IVYBRIDGE_X,		core_funcs),
-	ICPU(INTEL_FAM6_HASWELL_X,		core_funcs),
-	ICPU(INTEL_FAM6_HASWELL_L,		core_funcs),
-	ICPU(INTEL_FAM6_HASWELL_G,		core_funcs),
-	ICPU(INTEL_FAM6_BROADWELL_G,		core_funcs),
-	ICPU(INTEL_FAM6_ATOM_AIRMONT,		airmont_funcs),
-	ICPU(INTEL_FAM6_SKYLAKE_L,		core_funcs),
-	ICPU(INTEL_FAM6_BROADWELL_X,		core_funcs),
-	ICPU(INTEL_FAM6_SKYLAKE,		core_funcs),
-	ICPU(INTEL_FAM6_BROADWELL_D,		core_funcs),
-	ICPU(INTEL_FAM6_XEON_PHI_KNL,		knl_funcs),
-	ICPU(INTEL_FAM6_XEON_PHI_KNM,		knl_funcs),
-	ICPU(INTEL_FAM6_ATOM_GOLDMONT,		core_funcs),
-	ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,     core_funcs),
-	ICPU(INTEL_FAM6_SKYLAKE_X,		core_funcs),
+	X86_MATCH(SANDYBRIDGE,		core_funcs),
+	X86_MATCH(SANDYBRIDGE_X,	core_funcs),
+	X86_MATCH(ATOM_SILVERMONT,	silvermont_funcs),
+	X86_MATCH(IVYBRIDGE,		core_funcs),
+	X86_MATCH(HASWELL,		core_funcs),
+	X86_MATCH(BROADWELL,		core_funcs),
+	X86_MATCH(IVYBRIDGE_X,		core_funcs),
+	X86_MATCH(HASWELL_X,		core_funcs),
+	X86_MATCH(HASWELL_L,		core_funcs),
+	X86_MATCH(HASWELL_G,		core_funcs),
+	X86_MATCH(BROADWELL_G,		core_funcs),
+	X86_MATCH(ATOM_AIRMONT,		airmont_funcs),
+	X86_MATCH(SKYLAKE_L,		core_funcs),
+	X86_MATCH(BROADWELL_X,		core_funcs),
+	X86_MATCH(SKYLAKE,		core_funcs),
+	X86_MATCH(BROADWELL_D,		core_funcs),
+	X86_MATCH(XEON_PHI_KNL,		knl_funcs),
+	X86_MATCH(XEON_PHI_KNM,		knl_funcs),
+	X86_MATCH(ATOM_GOLDMONT,	core_funcs),
+	X86_MATCH(ATOM_GOLDMONT_PLUS,	core_funcs),
+	X86_MATCH(SKYLAKE_X,		core_funcs),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
 
 static const struct x86_cpu_id intel_pstate_cpu_oob_ids[] __initconst = {
-	ICPU(INTEL_FAM6_BROADWELL_D, core_funcs),
-	ICPU(INTEL_FAM6_BROADWELL_X, core_funcs),
-	ICPU(INTEL_FAM6_SKYLAKE_X, core_funcs),
+	X86_MATCH(BROADWELL_D,		core_funcs),
+	X86_MATCH(BROADWELL_X,		core_funcs),
+	X86_MATCH(SKYLAKE_X,		core_funcs),
 	{}
 };
 
 static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[] = {
-	ICPU(INTEL_FAM6_KABYLAKE, core_funcs),
+	X86_MATCH(KABYLAKE,		core_funcs),
 	{}
 };
 
 static const struct x86_cpu_id intel_pstate_hwp_boost_ids[] = {
-	ICPU(INTEL_FAM6_SKYLAKE_X, core_funcs),
-	ICPU(INTEL_FAM6_SKYLAKE, core_funcs),
+	X86_MATCH(SKYLAKE_X,		core_funcs),
+	X86_MATCH(SKYLAKE,		core_funcs),
 	{}
 };
 
@@ -2726,13 +2726,14 @@ static inline void intel_pstate_request_
 
 #define INTEL_PSTATE_HWP_BROADWELL	0x01
 
-#define ICPU_HWP(model, hwp_mode) \
-	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_HWP, hwp_mode }
+#define X86_MATCH_HWP(model, hwp_mode)					\
+	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
+					   X86_FEATURE_APERFMPERF, hwp_mode)
 
 static const struct x86_cpu_id hwp_support_ids[] __initconst = {
-	ICPU_HWP(INTEL_FAM6_BROADWELL_X, INTEL_PSTATE_HWP_BROADWELL),
-	ICPU_HWP(INTEL_FAM6_BROADWELL_D, INTEL_PSTATE_HWP_BROADWELL),
-	ICPU_HWP(X86_MODEL_ANY, 0),
+	X86_MATCH_HWP(BROADWELL_X,	INTEL_PSTATE_HWP_BROADWELL),
+	X86_MATCH_HWP(BROADWELL_D,	INTEL_PSTATE_HWP_BROADWELL),
+	X86_MATCH_HWP(ANY,		0),
 	{}
 };
 
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -910,7 +910,7 @@ static struct cpufreq_driver longhaul_dr
 };
 
 static const struct x86_cpu_id longhaul_id[] = {
-	{ X86_VENDOR_CENTAUR, 6 },
+	X86_MATCH_VENDOR_FAM(CENTAUR, 6, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, longhaul_id);
--- a/drivers/cpufreq/longrun.c
+++ b/drivers/cpufreq/longrun.c
@@ -281,8 +281,7 @@ static struct cpufreq_driver longrun_dri
 };
 
 static const struct x86_cpu_id longrun_ids[] = {
-	{ X86_VENDOR_TRANSMETA, X86_FAMILY_ANY, X86_MODEL_ANY,
-	  X86_FEATURE_LONGRUN },
+	X86_MATCH_VENDOR_FEATURE(TRANSMETA, X86_FEATURE_LONGRUN, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, longrun_ids);
--- a/drivers/cpufreq/p4-clockmod.c
+++ b/drivers/cpufreq/p4-clockmod.c
@@ -231,7 +231,7 @@ static struct cpufreq_driver p4clockmod_
 };
 
 static const struct x86_cpu_id cpufreq_p4_id[] = {
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_ACC },
+	X86_MATCH_VENDOR_FEATURE(INTEL, X86_FEATURE_ACC, NULL),
 	{}
 };
 
--- a/drivers/cpufreq/powernow-k6.c
+++ b/drivers/cpufreq/powernow-k6.c
@@ -258,8 +258,8 @@ static struct cpufreq_driver powernow_k6
 };
 
 static const struct x86_cpu_id powernow_k6_ids[] = {
-	{ X86_VENDOR_AMD, 5, 12 },
-	{ X86_VENDOR_AMD, 5, 13 },
+	X86_MATCH_VENDOR_FAM_MODEL(AMD, 5, 12, NULL),
+	X86_MATCH_VENDOR_FAM_MODEL(AMD, 5, 13, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, powernow_k6_ids);
--- a/drivers/cpufreq/powernow-k7.c
+++ b/drivers/cpufreq/powernow-k7.c
@@ -109,7 +109,7 @@ static int check_fsb(unsigned int fsbspe
 }
 
 static const struct x86_cpu_id powernow_k7_cpuids[] = {
-	{ X86_VENDOR_AMD, 6, },
+	X86_MATCH_VENDOR_FAM(AMD, 6, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, powernow_k7_cpuids);
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -452,7 +452,7 @@ static int core_voltage_post_transition(
 
 static const struct x86_cpu_id powernow_k8_ids[] = {
 	/* IO based frequency switching */
-	{ X86_VENDOR_AMD, 0xf },
+	X86_MATCH_VENDOR_FAM(AMD, 0xf, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, powernow_k8_ids);
--- a/drivers/cpufreq/sc520_freq.c
+++ b/drivers/cpufreq/sc520_freq.c
@@ -95,7 +95,7 @@ static struct cpufreq_driver sc520_freq_
 };
 
 static const struct x86_cpu_id sc520_ids[] = {
-	{ X86_VENDOR_AMD, 4, 9 },
+	X86_MATCH_VENDOR_FAM_MODEL(AMD, 4, 9, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, sc520_ids);
--- a/drivers/cpufreq/speedstep-centrino.c
+++ b/drivers/cpufreq/speedstep-centrino.c
@@ -520,18 +520,12 @@ static struct cpufreq_driver centrino_dr
  * or ASCII model IDs.
  */
 static const struct x86_cpu_id centrino_ids[] = {
-	{ X86_VENDOR_INTEL, 6, 9, X86_FEATURE_EST },
-	{ X86_VENDOR_INTEL, 6, 13, X86_FEATURE_EST },
-	{ X86_VENDOR_INTEL, 6, 13, X86_FEATURE_EST },
-	{ X86_VENDOR_INTEL, 6, 13, X86_FEATURE_EST },
-	{ X86_VENDOR_INTEL, 15, 3, X86_FEATURE_EST },
-	{ X86_VENDOR_INTEL, 15, 4, X86_FEATURE_EST },
+	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),
 	{}
 };
-#if 0
-/* Autoload or not? Do not for now. */
-MODULE_DEVICE_TABLE(x86cpu, centrino_ids);
-#endif
 
 /**
  * centrino_init - initializes the Enhanced SpeedStep CPUFreq driver
--- a/drivers/cpufreq/speedstep-ich.c
+++ b/drivers/cpufreq/speedstep-ich.c
@@ -319,15 +319,11 @@ static struct cpufreq_driver speedstep_d
 };
 
 static const struct x86_cpu_id ss_smi_ids[] = {
-	{ X86_VENDOR_INTEL, 6, 0xb, },
-	{ X86_VENDOR_INTEL, 6, 0x8, },
-	{ X86_VENDOR_INTEL, 15, 2 },
+	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),
 	{}
 };
-#if 0
-/* Autoload or not? Do not for now. */
-MODULE_DEVICE_TABLE(x86cpu, ss_smi_ids);
-#endif
 
 /**
  * speedstep_init - initializes the SpeedStep CPUFreq driver
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -299,15 +299,11 @@ static struct cpufreq_driver speedstep_d
 };
 
 static const struct x86_cpu_id ss_smi_ids[] = {
-	{ X86_VENDOR_INTEL, 6, 0xb, },
-	{ X86_VENDOR_INTEL, 6, 0x8, },
-	{ X86_VENDOR_INTEL, 15, 2 },
+	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),
 	{}
 };
-#if 0
-/* Not auto loaded currently */
-MODULE_DEVICE_TABLE(x86cpu, ss_smi_ids);
-#endif
 
 /**
  * speedstep_init - initializes the SpeedStep CPUFreq driver

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch V2 09/22] cpufreq: Convert to new X86 CPU match macros
  2020-03-24 13:51   ` [patch V2 09/22] cpufreq: Convert to new X86 CPU match macros Thomas Gleixner
@ 2020-03-24 15:37     ` Rafael J. Wysocki
  0 siblings, 0 replies; 26+ messages in thread
From: Rafael J. Wysocki @ 2020-03-24 15:37 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, the arch/x86 maintainers, Greg Kroah-Hartman, Mark Gross,
	Tony Luck, Rafael J. Wysocki, Viresh Kumar, Linux PM,
	Srinivas Pandruvada, Len Brown, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, ACPI Devel Maling List, open list:EDAC-CORE,
	Platform Driver, Jean Delvare, Guenter Roeck, linux-hwmon,
	Zhang Rui, Daniel Lezcano, Amit Kucheria, Chanwoo Choi,
	Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas,
	Linux PCI, Takashi Iwai,
	moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	Herbert Xu, David S. Miller, linux-crypto

On Tue, Mar 24, 2020 at 2:52 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The new macro set has a consistent namespace and uses C99 initializers
> instead of the grufty C89 ones.
>
> Get rid the of most local macro wrappers for consistency. The ones which
> make sense for readability are renamed to X86_MATCH*.
>
> In the centrino driver this also removes the two extra duplicates of family
> 6 model 13 which have no value at all.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: Len Brown <lenb@kernel.org>

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

> ---
> V2: Add the dropped terminator in the centrino speedstep driver back. (Andy)
> ---
>  drivers/cpufreq/acpi-cpufreq.c         |    4 -
>  drivers/cpufreq/amd_freq_sensitivity.c |    2
>  drivers/cpufreq/e_powersaver.c         |    2
>  drivers/cpufreq/elanfreq.c             |    2
>  drivers/cpufreq/intel_pstate.c         |   71 ++++++++++++++++-----------------
>  drivers/cpufreq/longhaul.c             |    2
>  drivers/cpufreq/longrun.c              |    3 -
>  drivers/cpufreq/p4-clockmod.c          |    2
>  drivers/cpufreq/powernow-k6.c          |    4 -
>  drivers/cpufreq/powernow-k7.c          |    2
>  drivers/cpufreq/powernow-k8.c          |    2
>  drivers/cpufreq/sc520_freq.c           |    2
>  drivers/cpufreq/speedstep-centrino.c   |   14 +-----
>  drivers/cpufreq/speedstep-ich.c        |   10 +---
>  drivers/cpufreq/speedstep-smi.c        |   10 +---
>  15 files changed, 59 insertions(+), 73 deletions(-)
>
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -991,8 +991,8 @@ late_initcall(acpi_cpufreq_init);
>  module_exit(acpi_cpufreq_exit);
>
>  static const struct x86_cpu_id acpi_cpufreq_ids[] = {
> -       X86_FEATURE_MATCH(X86_FEATURE_ACPI),
> -       X86_FEATURE_MATCH(X86_FEATURE_HW_PSTATE),
> +       X86_MATCH_FEATURE(X86_FEATURE_ACPI, NULL),
> +       X86_MATCH_FEATURE(X86_FEATURE_HW_PSTATE, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, acpi_cpufreq_ids);
> --- a/drivers/cpufreq/amd_freq_sensitivity.c
> +++ b/drivers/cpufreq/amd_freq_sensitivity.c
> @@ -144,7 +144,7 @@ static void __exit amd_freq_sensitivity_
>  module_exit(amd_freq_sensitivity_exit);
>
>  static const struct x86_cpu_id amd_freq_sensitivity_ids[] = {
> -       X86_FEATURE_MATCH(X86_FEATURE_PROC_FEEDBACK),
> +       X86_MATCH_FEATURE(X86_FEATURE_PROC_FEEDBACK, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, amd_freq_sensitivity_ids);
> --- a/drivers/cpufreq/e_powersaver.c
> +++ b/drivers/cpufreq/e_powersaver.c
> @@ -385,7 +385,7 @@ static struct cpufreq_driver eps_driver
>  /* This driver will work only on Centaur C7 processors with
>   * Enhanced SpeedStep/PowerSaver registers */
>  static const struct x86_cpu_id eps_cpu_id[] = {
> -       { X86_VENDOR_CENTAUR, 6, X86_MODEL_ANY, X86_FEATURE_EST },
> +       X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_EST, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, eps_cpu_id);
> --- a/drivers/cpufreq/elanfreq.c
> +++ b/drivers/cpufreq/elanfreq.c
> @@ -198,7 +198,7 @@ static struct cpufreq_driver elanfreq_dr
>  };
>
>  static const struct x86_cpu_id elan_id[] = {
> -       { X86_VENDOR_AMD, 4, 10, },
> +       X86_MATCH_VENDOR_FAM_MODEL(AMD, 4, 10, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, elan_id);
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1909,51 +1909,51 @@ static const struct pstate_funcs knl_fun
>         .get_val = core_get_val,
>  };
>
> -#define ICPU(model, policy) \
> -       { X86_VENDOR_INTEL, 6, model, X86_FEATURE_APERFMPERF,\
> -                       (unsigned long)&policy }
> +#define X86_MATCH(model, policy)                                        \
> +       X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
> +                                          X86_FEATURE_APERFMPERF, &policy)
>
>  static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
> -       ICPU(INTEL_FAM6_SANDYBRIDGE,            core_funcs),
> -       ICPU(INTEL_FAM6_SANDYBRIDGE_X,          core_funcs),
> -       ICPU(INTEL_FAM6_ATOM_SILVERMONT,        silvermont_funcs),
> -       ICPU(INTEL_FAM6_IVYBRIDGE,              core_funcs),
> -       ICPU(INTEL_FAM6_HASWELL,                core_funcs),
> -       ICPU(INTEL_FAM6_BROADWELL,              core_funcs),
> -       ICPU(INTEL_FAM6_IVYBRIDGE_X,            core_funcs),
> -       ICPU(INTEL_FAM6_HASWELL_X,              core_funcs),
> -       ICPU(INTEL_FAM6_HASWELL_L,              core_funcs),
> -       ICPU(INTEL_FAM6_HASWELL_G,              core_funcs),
> -       ICPU(INTEL_FAM6_BROADWELL_G,            core_funcs),
> -       ICPU(INTEL_FAM6_ATOM_AIRMONT,           airmont_funcs),
> -       ICPU(INTEL_FAM6_SKYLAKE_L,              core_funcs),
> -       ICPU(INTEL_FAM6_BROADWELL_X,            core_funcs),
> -       ICPU(INTEL_FAM6_SKYLAKE,                core_funcs),
> -       ICPU(INTEL_FAM6_BROADWELL_D,            core_funcs),
> -       ICPU(INTEL_FAM6_XEON_PHI_KNL,           knl_funcs),
> -       ICPU(INTEL_FAM6_XEON_PHI_KNM,           knl_funcs),
> -       ICPU(INTEL_FAM6_ATOM_GOLDMONT,          core_funcs),
> -       ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,     core_funcs),
> -       ICPU(INTEL_FAM6_SKYLAKE_X,              core_funcs),
> +       X86_MATCH(SANDYBRIDGE,          core_funcs),
> +       X86_MATCH(SANDYBRIDGE_X,        core_funcs),
> +       X86_MATCH(ATOM_SILVERMONT,      silvermont_funcs),
> +       X86_MATCH(IVYBRIDGE,            core_funcs),
> +       X86_MATCH(HASWELL,              core_funcs),
> +       X86_MATCH(BROADWELL,            core_funcs),
> +       X86_MATCH(IVYBRIDGE_X,          core_funcs),
> +       X86_MATCH(HASWELL_X,            core_funcs),
> +       X86_MATCH(HASWELL_L,            core_funcs),
> +       X86_MATCH(HASWELL_G,            core_funcs),
> +       X86_MATCH(BROADWELL_G,          core_funcs),
> +       X86_MATCH(ATOM_AIRMONT,         airmont_funcs),
> +       X86_MATCH(SKYLAKE_L,            core_funcs),
> +       X86_MATCH(BROADWELL_X,          core_funcs),
> +       X86_MATCH(SKYLAKE,              core_funcs),
> +       X86_MATCH(BROADWELL_D,          core_funcs),
> +       X86_MATCH(XEON_PHI_KNL,         knl_funcs),
> +       X86_MATCH(XEON_PHI_KNM,         knl_funcs),
> +       X86_MATCH(ATOM_GOLDMONT,        core_funcs),
> +       X86_MATCH(ATOM_GOLDMONT_PLUS,   core_funcs),
> +       X86_MATCH(SKYLAKE_X,            core_funcs),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
>
>  static const struct x86_cpu_id intel_pstate_cpu_oob_ids[] __initconst = {
> -       ICPU(INTEL_FAM6_BROADWELL_D, core_funcs),
> -       ICPU(INTEL_FAM6_BROADWELL_X, core_funcs),
> -       ICPU(INTEL_FAM6_SKYLAKE_X, core_funcs),
> +       X86_MATCH(BROADWELL_D,          core_funcs),
> +       X86_MATCH(BROADWELL_X,          core_funcs),
> +       X86_MATCH(SKYLAKE_X,            core_funcs),
>         {}
>  };
>
>  static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[] = {
> -       ICPU(INTEL_FAM6_KABYLAKE, core_funcs),
> +       X86_MATCH(KABYLAKE,             core_funcs),
>         {}
>  };
>
>  static const struct x86_cpu_id intel_pstate_hwp_boost_ids[] = {
> -       ICPU(INTEL_FAM6_SKYLAKE_X, core_funcs),
> -       ICPU(INTEL_FAM6_SKYLAKE, core_funcs),
> +       X86_MATCH(SKYLAKE_X,            core_funcs),
> +       X86_MATCH(SKYLAKE,              core_funcs),
>         {}
>  };
>
> @@ -2726,13 +2726,14 @@ static inline void intel_pstate_request_
>
>  #define INTEL_PSTATE_HWP_BROADWELL     0x01
>
> -#define ICPU_HWP(model, hwp_mode) \
> -       { X86_VENDOR_INTEL, 6, model, X86_FEATURE_HWP, hwp_mode }
> +#define X86_MATCH_HWP(model, hwp_mode)                                 \
> +       X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
> +                                          X86_FEATURE_APERFMPERF, hwp_mode)
>
>  static const struct x86_cpu_id hwp_support_ids[] __initconst = {
> -       ICPU_HWP(INTEL_FAM6_BROADWELL_X, INTEL_PSTATE_HWP_BROADWELL),
> -       ICPU_HWP(INTEL_FAM6_BROADWELL_D, INTEL_PSTATE_HWP_BROADWELL),
> -       ICPU_HWP(X86_MODEL_ANY, 0),
> +       X86_MATCH_HWP(BROADWELL_X,      INTEL_PSTATE_HWP_BROADWELL),
> +       X86_MATCH_HWP(BROADWELL_D,      INTEL_PSTATE_HWP_BROADWELL),
> +       X86_MATCH_HWP(ANY,              0),
>         {}
>  };
>
> --- a/drivers/cpufreq/longhaul.c
> +++ b/drivers/cpufreq/longhaul.c
> @@ -910,7 +910,7 @@ static struct cpufreq_driver longhaul_dr
>  };
>
>  static const struct x86_cpu_id longhaul_id[] = {
> -       { X86_VENDOR_CENTAUR, 6 },
> +       X86_MATCH_VENDOR_FAM(CENTAUR, 6, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, longhaul_id);
> --- a/drivers/cpufreq/longrun.c
> +++ b/drivers/cpufreq/longrun.c
> @@ -281,8 +281,7 @@ static struct cpufreq_driver longrun_dri
>  };
>
>  static const struct x86_cpu_id longrun_ids[] = {
> -       { X86_VENDOR_TRANSMETA, X86_FAMILY_ANY, X86_MODEL_ANY,
> -         X86_FEATURE_LONGRUN },
> +       X86_MATCH_VENDOR_FEATURE(TRANSMETA, X86_FEATURE_LONGRUN, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, longrun_ids);
> --- a/drivers/cpufreq/p4-clockmod.c
> +++ b/drivers/cpufreq/p4-clockmod.c
> @@ -231,7 +231,7 @@ static struct cpufreq_driver p4clockmod_
>  };
>
>  static const struct x86_cpu_id cpufreq_p4_id[] = {
> -       { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_ACC },
> +       X86_MATCH_VENDOR_FEATURE(INTEL, X86_FEATURE_ACC, NULL),
>         {}
>  };
>
> --- a/drivers/cpufreq/powernow-k6.c
> +++ b/drivers/cpufreq/powernow-k6.c
> @@ -258,8 +258,8 @@ static struct cpufreq_driver powernow_k6
>  };
>
>  static const struct x86_cpu_id powernow_k6_ids[] = {
> -       { X86_VENDOR_AMD, 5, 12 },
> -       { X86_VENDOR_AMD, 5, 13 },
> +       X86_MATCH_VENDOR_FAM_MODEL(AMD, 5, 12, NULL),
> +       X86_MATCH_VENDOR_FAM_MODEL(AMD, 5, 13, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, powernow_k6_ids);
> --- a/drivers/cpufreq/powernow-k7.c
> +++ b/drivers/cpufreq/powernow-k7.c
> @@ -109,7 +109,7 @@ static int check_fsb(unsigned int fsbspe
>  }
>
>  static const struct x86_cpu_id powernow_k7_cpuids[] = {
> -       { X86_VENDOR_AMD, 6, },
> +       X86_MATCH_VENDOR_FAM(AMD, 6, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, powernow_k7_cpuids);
> --- a/drivers/cpufreq/powernow-k8.c
> +++ b/drivers/cpufreq/powernow-k8.c
> @@ -452,7 +452,7 @@ static int core_voltage_post_transition(
>
>  static const struct x86_cpu_id powernow_k8_ids[] = {
>         /* IO based frequency switching */
> -       { X86_VENDOR_AMD, 0xf },
> +       X86_MATCH_VENDOR_FAM(AMD, 0xf, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, powernow_k8_ids);
> --- a/drivers/cpufreq/sc520_freq.c
> +++ b/drivers/cpufreq/sc520_freq.c
> @@ -95,7 +95,7 @@ static struct cpufreq_driver sc520_freq_
>  };
>
>  static const struct x86_cpu_id sc520_ids[] = {
> -       { X86_VENDOR_AMD, 4, 9 },
> +       X86_MATCH_VENDOR_FAM_MODEL(AMD, 4, 9, NULL),
>         {}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, sc520_ids);
> --- a/drivers/cpufreq/speedstep-centrino.c
> +++ b/drivers/cpufreq/speedstep-centrino.c
> @@ -520,18 +520,12 @@ static struct cpufreq_driver centrino_dr
>   * or ASCII model IDs.
>   */
>  static const struct x86_cpu_id centrino_ids[] = {
> -       { X86_VENDOR_INTEL, 6, 9, X86_FEATURE_EST },
> -       { X86_VENDOR_INTEL, 6, 13, X86_FEATURE_EST },
> -       { X86_VENDOR_INTEL, 6, 13, X86_FEATURE_EST },
> -       { X86_VENDOR_INTEL, 6, 13, X86_FEATURE_EST },
> -       { X86_VENDOR_INTEL, 15, 3, X86_FEATURE_EST },
> -       { X86_VENDOR_INTEL, 15, 4, X86_FEATURE_EST },
> +       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),
>         {}
>  };
> -#if 0
> -/* Autoload or not? Do not for now. */
> -MODULE_DEVICE_TABLE(x86cpu, centrino_ids);
> -#endif
>
>  /**
>   * centrino_init - initializes the Enhanced SpeedStep CPUFreq driver
> --- a/drivers/cpufreq/speedstep-ich.c
> +++ b/drivers/cpufreq/speedstep-ich.c
> @@ -319,15 +319,11 @@ static struct cpufreq_driver speedstep_d
>  };
>
>  static const struct x86_cpu_id ss_smi_ids[] = {
> -       { X86_VENDOR_INTEL, 6, 0xb, },
> -       { X86_VENDOR_INTEL, 6, 0x8, },
> -       { X86_VENDOR_INTEL, 15, 2 },
> +       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),
>         {}
>  };
> -#if 0
> -/* Autoload or not? Do not for now. */
> -MODULE_DEVICE_TABLE(x86cpu, ss_smi_ids);
> -#endif
>
>  /**
>   * speedstep_init - initializes the SpeedStep CPUFreq driver
> --- a/drivers/cpufreq/speedstep-smi.c
> +++ b/drivers/cpufreq/speedstep-smi.c
> @@ -299,15 +299,11 @@ static struct cpufreq_driver speedstep_d
>  };
>
>  static const struct x86_cpu_id ss_smi_ids[] = {
> -       { X86_VENDOR_INTEL, 6, 0xb, },
> -       { X86_VENDOR_INTEL, 6, 0x8, },
> -       { X86_VENDOR_INTEL, 15, 2 },
> +       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),
>         {}
>  };
> -#if 0
> -/* Not auto loaded currently */
> -MODULE_DEVICE_TABLE(x86cpu, ss_smi_ids);
> -#endif
>
>  /**
>   * speedstep_init - initializes the SpeedStep CPUFreq driver

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression
  2020-03-24 10:24     ` [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression Andy Shevchenko
@ 2020-03-24 15:38       ` Srinivas Pandruvada
  2020-03-25  7:51         ` Rong Chen
  2020-03-25  7:50       ` Rong Chen
  1 sibling, 1 reply; 26+ messages in thread
From: Srinivas Pandruvada @ 2020-03-24 15:38 UTC (permalink / raw)
  To: Andy Shevchenko, kernel test robot
  Cc: Thomas Gleixner, LKML,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Len Brown, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, ACPI Devel Maling List, linux-edac,
	Platform Driver, Jean Delvare, Guenter Roeck, linux-hwmon,
	Zhang Rui, Daniel Lezcano, Amit Kucheria, Chanwoo Choi,
	Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas,
	linux-pci, Takashi Iwai, ALSA Development Mailing List,
	Herbert Xu, David S. Miller, linux-crypto, lkp

On Tue, 2020-03-24 at 12:24 +0200, Andy Shevchenko wrote:
> On Tue, Mar 24, 2020 at 8:02 AM kernel test robot <
> rong.a.chen@intel.com> wrote:
> > Greeting,
> > 
> > FYI, we noticed a -53.4% regression of will-it-
> > scale.per_process_ops due to commit:
> > commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22]
> > cpufreq: Convert to new X86 CPU match macros")
> > url: 
> > https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729
> > base: 
> > https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git
> > linux-next
> > 
> > in testcase: will-it-scale
> > on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz
> > with 8G memory
> > with following parameters:
> 
> drivers/cpufreq/speedstep-centrino.c change missed the terminator,
> perhaps it's a culprit, because I don't believe removing dups and
> reordering lines may affect this.
> Can you restore terminator there and re-test?

This is a Ivy Bridge. So if it has to do anything cpufreq then it is
not loading the cpufreq driver (intel_pstate or acpi_cpufreq).
What is
 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor


> 


^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH 23/22] x86/smpboot: Remove the last ICPU() macro
       [not found] <20200320131345.635023594@linutronix.de>
                   ` (7 preceding siblings ...)
       [not found] ` <20200320131509.564059710@linutronix.de>
@ 2020-03-24 18:58 ` Borislav Petkov
       [not found] ` <20200320131509.673579000@linutronix.de>
  9 siblings, 0 replies; 26+ messages in thread
From: Borislav Petkov @ 2020-03-24 18:58 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, x86, Greg Kroah-Hartman, Mark Gross, Tony Luck,
	Paolo Bonzini, Darren Hart, Andy Shevchenko, Rafael J. Wysocki,
	Len Brown, linux-acpi, Viresh Kumar, linux-pm,
	Srinivas Pandruvada, linux-edac, platform-driver-x86,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, alsa-devel, Herbert Xu, David S. Miller,
	linux-crypto

---
From: Borislav Petkov <bp@suse.de>

Now all is using the shiny new macros.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/smpboot.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index fe3ab9632f3b..3b9bf8c7e29d 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1849,24 +1849,25 @@ static bool slv_set_max_freq_ratio(u64 *base_freq, u64 *turbo_freq)
 #include <asm/cpu_device_id.h>
 #include <asm/intel-family.h>
 
-#define ICPU(model) \
-	{X86_VENDOR_INTEL, 6, model, X86_FEATURE_APERFMPERF, 0}
+#define X86_MATCH(model)					\
+	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6,		\
+		INTEL_FAM6_##model, X86_FEATURE_APERFMPERF, NULL)
 
 static const struct x86_cpu_id has_knl_turbo_ratio_limits[] = {
-	ICPU(INTEL_FAM6_XEON_PHI_KNL),
-	ICPU(INTEL_FAM6_XEON_PHI_KNM),
+	X86_MATCH(XEON_PHI_KNL),
+	X86_MATCH(XEON_PHI_KNM),
 	{}
 };
 
 static const struct x86_cpu_id has_skx_turbo_ratio_limits[] = {
-	ICPU(INTEL_FAM6_SKYLAKE_X),
+	X86_MATCH(SKYLAKE_X),
 	{}
 };
 
 static const struct x86_cpu_id has_glm_turbo_ratio_limits[] = {
-	ICPU(INTEL_FAM6_ATOM_GOLDMONT),
-	ICPU(INTEL_FAM6_ATOM_GOLDMONT_D),
-	ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS),
+	X86_MATCH(ATOM_GOLDMONT),
+	X86_MATCH(ATOM_GOLDMONT_D),
+	X86_MATCH(ATOM_GOLDMONT_PLUS),
 	{}
 };
 
-- 
2.21.0


-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [patch 10/22] EDAC: Convert to new X86 CPU match macros
       [not found] ` <20200320131509.673579000@linutronix.de>
@ 2020-03-24 19:31   ` Luck, Tony
  0 siblings, 0 replies; 26+ messages in thread
From: Luck, Tony @ 2020-03-24 19:31 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, x86, Greg Kroah-Hartman, Mark Gross, linux-edac,
	Paolo Bonzini, Darren Hart, Andy Shevchenko, Rafael J. Wysocki,
	Len Brown, linux-acpi, Viresh Kumar, linux-pm,
	Srinivas Pandruvada, platform-driver-x86, Jean Delvare,
	Guenter Roeck, linux-hwmon, Zhang Rui, Daniel Lezcano,
	Amit Kucheria, Chanwoo Choi, Jacob Pan, Adrian Hunter,
	Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci, Takashi Iwai,
	alsa-devel, Herbert Xu, David S. Miller, linux-crypto

On Fri, Mar 20, 2020 at 02:13:55PM +0100, Thomas Gleixner wrote:
> The new macro set has a consistent namespace and uses C99 initializers
> instead of the grufty C89 ones.
                 ^^^^^^

grufty? Did you mean crufty?

Though I suppose grufty may work as well here:

	gruft. Noun. (uncountable) (dialect) the particles of soil
	that are spattered up onto grass by the rain.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Tested the Broadwell EDAC driver. The other changes look
good too.

Acked-by: Tony Luck <tony.luck@intel.com>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression
  2020-03-24 10:24     ` [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression Andy Shevchenko
  2020-03-24 15:38       ` Srinivas Pandruvada
@ 2020-03-25  7:50       ` Rong Chen
  2020-03-25 10:32         ` Thomas Gleixner
  1 sibling, 1 reply; 26+ messages in thread
From: Rong Chen @ 2020-03-25  7:50 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Thomas Gleixner, LKML,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto, lkp



On 3/24/20 6:24 PM, Andy Shevchenko wrote:
> On Tue, Mar 24, 2020 at 8:02 AM kernel test robot <rong.a.chen@intel.com> wrote:
>> Greeting,
>>
>> FYI, we noticed a -53.4% regression of will-it-scale.per_process_ops due to commit:
>> commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22] cpufreq: Convert to new X86 CPU match macros")
>> url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729
>> base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next
>>
>> in testcase: will-it-scale
>> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory
>> with following parameters:
>
> drivers/cpufreq/speedstep-centrino.c change missed the terminator,
> perhaps it's a culprit, because I don't believe removing dups and
> reordering lines may affect this.
> Can you restore terminator there and re-test?
>

I have retested with the change, but it has no effect on the performance.

Best Regards,
Rong Chen

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression
  2020-03-24 15:38       ` Srinivas Pandruvada
@ 2020-03-25  7:51         ` Rong Chen
  0 siblings, 0 replies; 26+ messages in thread
From: Rong Chen @ 2020-03-25  7:51 UTC (permalink / raw)
  To: Srinivas Pandruvada, Andy Shevchenko
  Cc: Thomas Gleixner, LKML,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Len Brown, Paolo Bonzini, Darren Hart,
	Andy Shevchenko, ACPI Devel Maling List, linux-edac,
	Platform Driver, Jean Delvare, Guenter Roeck, linux-hwmon,
	Zhang Rui, Daniel Lezcano, Amit Kucheria, Chanwoo Choi,
	Jacob Pan, Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas,
	linux-pci, Takashi Iwai, ALSA Development Mailing List,
	Herbert Xu, David S. Miller, linux-crypto, lkp



On 3/24/20 11:38 PM, Srinivas Pandruvada wrote:
> On Tue, 2020-03-24 at 12:24 +0200, Andy Shevchenko wrote:
>> On Tue, Mar 24, 2020 at 8:02 AM kernel test robot <
>> rong.a.chen@intel.com> wrote:
>>> Greeting,
>>>
>>> FYI, we noticed a -53.4% regression of will-it-
>>> scale.per_process_ops due to commit:
>>> commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22]
>>> cpufreq: Convert to new X86 CPU match macros")
>>> url:
>>> https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729
>>> base:
>>> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git
>>> linux-next
>>>
>>> in testcase: will-it-scale
>>> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz
>>> with 8G memory
>>> with following parameters:
>> drivers/cpufreq/speedstep-centrino.c change missed the terminator,
>> perhaps it's a culprit, because I don't believe removing dups and
>> reordering lines may affect this.
>> Can you restore terminator there and re-test?
> This is a Ivy Bridge. So if it has to do anything cpufreq then it is
> not loading the cpufreq driver (intel_pstate or acpi_cpufreq).
> What is
>   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression
  2020-03-25  7:50       ` Rong Chen
@ 2020-03-25 10:32         ` Thomas Gleixner
  2020-03-26  8:33           ` kernel test robot
  0 siblings, 1 reply; 26+ messages in thread
From: Thomas Gleixner @ 2020-03-25 10:32 UTC (permalink / raw)
  To: Rong Chen, Andy Shevchenko
  Cc: LKML, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto, lkp

Rong Chen <rong.a.chen@intel.com> writes:
> On 3/24/20 6:24 PM, Andy Shevchenko wrote:
>> On Tue, Mar 24, 2020 at 8:02 AM kernel test robot <rong.a.chen@intel.com> wrote:
>>> Greeting,
>>>
>>> FYI, we noticed a -53.4% regression of will-it-scale.per_process_ops due to commit:
>>> commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22] cpufreq: Convert to new X86 CPU match macros")
>>> url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729
>>> base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next
>>>
>>> in testcase: will-it-scale
>>> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory
>>> with following parameters:
>>
>> drivers/cpufreq/speedstep-centrino.c change missed the terminator,
>> perhaps it's a culprit, because I don't believe removing dups and
>> reordering lines may affect this.
>> Can you restore terminator there and re-test?
>>
>
> I have retested with the change, but it has no effect on the performance.

Bah. The binary equivalence testing detected this, but I obvioulsy
missed it. Delta fix below.

Thanks,

        tglx

8<--------------
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2727,7 +2727,7 @@ static inline void intel_pstate_request_
 
 #define X86_MATCH_HWP(model, hwp_mode)					\
 	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
-					   X86_FEATURE_APERFMPERF, hwp_mode)
+					   X86_FEATURE_HWP, hwp_mode)
 
 static const struct x86_cpu_id hwp_support_ids[] __initconst = {
 	X86_MATCH_HWP(BROADWELL_X,	INTEL_PSTATE_HWP_BROADWELL),

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression
  2020-03-25 10:32         ` Thomas Gleixner
@ 2020-03-26  8:33           ` kernel test robot
  0 siblings, 0 replies; 26+ messages in thread
From: kernel test robot @ 2020-03-26  8:33 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Andy Shevchenko, LKML,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Greg Kroah-Hartman, Mark Gross, Tony Luck, Rafael J. Wysocki,
	Viresh Kumar, Linux PM, Srinivas Pandruvada, Len Brown,
	Paolo Bonzini, Darren Hart, Andy Shevchenko,
	ACPI Devel Maling List, linux-edac, Platform Driver,
	Jean Delvare, Guenter Roeck, linux-hwmon, Zhang Rui,
	Daniel Lezcano, Amit Kucheria, Chanwoo Choi, Jacob Pan,
	Adrian Hunter, Ulf Hansson, linux-mmc, Bjorn Helgaas, linux-pci,
	Takashi Iwai, ALSA Development Mailing List, Herbert Xu,
	David S. Miller, linux-crypto, lkp

On Wed, Mar 25, 2020 at 11:32:06AM +0100, Thomas Gleixner wrote:
> Rong Chen <rong.a.chen@intel.com> writes:
> > On 3/24/20 6:24 PM, Andy Shevchenko wrote:
> >> On Tue, Mar 24, 2020 at 8:02 AM kernel test robot <rong.a.chen@intel.com> wrote:
> >>> Greeting,
> >>>
> >>> FYI, we noticed a -53.4% regression of will-it-scale.per_process_ops due to commit:
> >>> commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22] cpufreq: Convert to new X86 CPU match macros")
> >>> url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729
> >>> base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next
> >>>
> >>> in testcase: will-it-scale
> >>> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory
> >>> with following parameters:
> >>
> >> drivers/cpufreq/speedstep-centrino.c change missed the terminator,
> >> perhaps it's a culprit, because I don't believe removing dups and
> >> reordering lines may affect this.
> >> Can you restore terminator there and re-test?
> >>
> >
> > I have retested with the change, but it has no effect on the performance.
> 
> Bah. The binary equivalence testing detected this, but I obvioulsy
> missed it. Delta fix below.
> 
> Thanks,
> 
>         tglx
> 
> 8<--------------
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -2727,7 +2727,7 @@ static inline void intel_pstate_request_
>  
>  #define X86_MATCH_HWP(model, hwp_mode)					\
>  	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
> -					   X86_FEATURE_APERFMPERF, hwp_mode)
> +					   X86_FEATURE_HWP, hwp_mode)
>  
>  static const struct x86_cpu_id hwp_support_ids[] __initconst = {
>  	X86_MATCH_HWP(BROADWELL_X,	INTEL_PSTATE_HWP_BROADWELL),

Hi Thomas,

The patch can fix the regression:

commit: 
  06c4d00466 ("cpufreq: Convert to new X86 CPU match macros")
  d369f9be1a ("the fix patch")

06c4d00466eb3748  d369f9be1ad1e22da4e8f03557  testcase/testparams/testbox
----------------  --------------------------  ---------------------------
         %stddev      change         %stddev
             \          |                \  
     93200             114%     199599        will-it-scale/performance-process-16-read2-ucode=0x21/lkp-ivb-d02
     93200             114%     199599        GEO-MEAN will-it-scale.per_process_ops

Best Regards,
Rong Chen

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, back to index

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200320131345.635023594@linutronix.de>
2020-03-20 14:31 ` [patch 00/22] x86/treewide: Consolidate CPU match macro maze and get rid of C89 (sic!) initializers Andy Shevchenko
     [not found] ` <20200320131508.736205164@linutronix.de>
2020-03-20 14:33   ` [patch 01/22] x86/devicetable: Move x86 specific macro out of generic code Andy Shevchenko
2020-03-20 20:24     ` Thomas Gleixner
     [not found] ` <20200320131508.826011988@linutronix.de>
2020-03-20 14:29   ` [patch 02/22] x86/cpu: Add conistent CPU match macros Bjorn Helgaas
2020-03-20 14:39   ` Andy Shevchenko
2020-03-20 20:27     ` Thomas Gleixner
     [not found] ` <20200320131509.467730627@linutronix.de>
2020-03-20 14:47   ` [patch 08/22] ACPI: Convert to new X86 " Andy Shevchenko
2020-03-20 20:32     ` Thomas Gleixner
2020-03-23 16:38       ` mark gross
     [not found] ` <20200320131509.766573641@linutronix.de>
2020-03-20 14:52   ` [patch 11/22] platform/x86: Convert to new " Andy Shevchenko
     [not found] ` <20200320131510.594671507@linutronix.de>
2020-03-20 14:58   ` [patch 19/22] ASoC: Intel: Convert to new X86 " Andy Shevchenko
2020-03-20 14:59 ` [patch 00/22] x86/treewide: Consolidate CPU match macro maze and get rid of C89 (sic!) initializers Greg Kroah-Hartman
     [not found] ` <20200320131509.564059710@linutronix.de>
2020-03-20 14:50   ` [patch 09/22] cpufreq: Convert to new X86 CPU match macros Andy Shevchenko
2020-03-20 20:30     ` Thomas Gleixner
2020-03-20 21:52       ` Andy Shevchenko
2020-03-20 22:18         ` Thomas Gleixner
     [not found]   ` <20200324060124.GC11705@shao2-debian>
2020-03-24 10:24     ` [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression Andy Shevchenko
2020-03-24 15:38       ` Srinivas Pandruvada
2020-03-25  7:51         ` Rong Chen
2020-03-25  7:50       ` Rong Chen
2020-03-25 10:32         ` Thomas Gleixner
2020-03-26  8:33           ` kernel test robot
2020-03-24 13:51   ` [patch V2 09/22] cpufreq: Convert to new X86 CPU match macros Thomas Gleixner
2020-03-24 15:37     ` Rafael J. Wysocki
2020-03-24 18:58 ` [PATCH 23/22] x86/smpboot: Remove the last ICPU() macro Borislav Petkov
     [not found] ` <20200320131509.673579000@linutronix.de>
2020-03-24 19:31   ` [patch 10/22] EDAC: Convert to new X86 CPU match macros Luck, Tony

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git