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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VdKavBD=yTR6Mz4iaGKQVP__xCsf-fWdy1MMJJywhDd-Q@mail.gmail.com>
Date:   Fri, 20 Mar 2020 16:39:16 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Gross <mgross@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        linux-edac@...r.kernel.org,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-hwmon@...r.kernel.org, Zhang Rui <rui.zhang@...el.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Amit Kucheria <amit.kucheria@...durent.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
        Takashi Iwai <tiwai@...e.com>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        linux-crypto <linux-crypto@...r.kernel.org>
Subject: Re: [patch 02/22] x86/cpu: Add conistent CPU match macros

On Fri, Mar 20, 2020 at 3:18 PM Thomas Gleixner <tglx@...utronix.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