Re: [patch 02/22] x86/cpu: Add conistent CPU match macros

Re: [patch 02/22] x86/cpu: Add conistent CPU match macros

[Bjorn Helgaas]

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/

Re: [patch 02/22] x86/cpu: Add conistent CPU match macros

[Andy Shevchenko]

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

Re: [patch 02/22] x86/cpu: Add conistent CPU match macros

[Thomas Gleixner]

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

Re: [patch 00/22] x86/treewide: Consolidate CPU match macro maze and get rid of C89 (sic!) initializers

[Andy Shevchenko]

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

Re: [patch 01/22] x86/devicetable: Move x86 specific macro out of generic code

[Andy Shevchenko]

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

Re: [patch 01/22] x86/devicetable: Move x86 specific macro out of generic code

[Thomas Gleixner]

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

Re: [patch 08/22] ACPI: Convert to new X86 CPU match macros

[Andy Shevchenko]

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

Re: [patch 08/22] ACPI: Convert to new X86 CPU match macros

[Thomas Gleixner]

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

Re: [patch 08/22] ACPI: Convert to new X86 CPU match macros

[mark gross]

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

Re: [patch 11/22] platform/x86: Convert to new CPU match macros

[Andy Shevchenko]

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

Re: [patch 19/22] ASoC: Intel: Convert to new X86 CPU match macros

[Andy Shevchenko]

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

Re: [patch 00/22] x86/treewide: Consolidate CPU match macro maze and get rid of C89 (sic!) initializers

[Greg Kroah-Hartman]

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>

Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros

[Andy Shevchenko]

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

Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros

[Thomas Gleixner]

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

Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros

[Andy Shevchenko]

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

Re: [patch 09/22] cpufreq: Convert to new X86 CPU match macros

[Thomas Gleixner]

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

Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression

[Andy Shevchenko]

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

Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression

[Srinivas Pandruvada]

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


> 

Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression

[Rong Chen]

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

Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression

[Rong Chen]

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

Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression

[Thomas Gleixner]

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),

Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression

[kernel test robot]

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

[patch V2 09/22] cpufreq: Convert to new X86 CPU match macros

[Thomas Gleixner]

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

Re: [patch V2 09/22] cpufreq: Convert to new X86 CPU match macros

[Rafael J. Wysocki]

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

[PATCH 23/22] x86/smpboot: Remove the last ICPU() macro

[Borislav Petkov]

---
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

Re: [patch 10/22] EDAC: Convert to new X86 CPU match macros

[Luck, Tony]

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>