historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 1/3] v4 more sampling fun 1
Date: Thu, 19 Mar 2020 09:50:40 +0100	[thread overview]
Message-ID: <20200319085040.GA3494118@kroah.com> (raw)
In-Reply-To: <5e7296c7.1c69fb81.f9a2f.00ebSMTPIN_ADDED_BROKEN@mx.google.com>

On Mon, Mar 16, 2020 at 05:56:27PM -0700, speck for mark gross wrote:
> From: mark gross <mgross@linux.intel.com>
> Subject: [PATCH 1/3] x86/cpu: Add stepping field to x86_cpu_id structure
> 
> Intel uses the same family/model for several CPUs. Sometimes
> the stepping must be checked to tell them apart.
> 
> Note that to keep this patch simple the new field has been added at the
> end to avoid churn with all the pre-C99 initialized uses of this
> structure. Such legacy usage will result in a "0" value for the stepping
> field, hence X86_STEPPING_ANY is defined as "0".

Are you sure about the "avoid churn" stuff?  Can't you just fix up the
X86_FEATURE_MATCH() #define to do that?

Also INTEL_CPU_FAM_ANY() already uses named identifiers, so you are ok
with that usage.  How many other places is this "open coded" that would
need to be fixed up.  Can't be more than 10-20, right?

> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -665,6 +665,7 @@ struct x86_cpu_id {
>  	__u16 model;
>  	__u16 feature;	/* bit index */
>  	kernel_ulong_t driver_data;
> +	__u16 stepping;
>  };

That just makes my eyes hurt, stepping really should be before
driver_data.

The macros should be fixed up anyway to use named identifiers, no time
like the present :)

And this, and the cleanups, can be done in public, like I thought we
asked for before, right?

thanks,

greg k-h

  parent reply	other threads:[~2020-03-19  8:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 21:27 [MODERATED] [PATCH 0/3] v4 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 2/3] v4 more sampling fun 2 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 3/3] v4 more sampling fun 3 mark gross
2020-03-17  0:56 ` [MODERATED] [PATCH 1/3] v4 more sampling fun 1 mark gross
     [not found] ` <5e7296c7.1c69fb81.f9a2f.00ebSMTPIN_ADDED_BROKEN@mx.google.com>
2020-03-19  8:50   ` Greg KH [this message]
2020-03-19 15:40     ` [MODERATED] " mark gross
2020-03-19 15:50       ` Luck, Tony
2020-03-19 16:34         ` Greg KH
2020-03-19 18:13     ` Thomas Gleixner
2020-03-26  3:19 ` [MODERATED] Re: [PATCH 2/3] v4 more sampling fun 2 Josh Poimboeuf
2020-03-27 16:20   ` mark gross
2020-03-27 17:23     ` Luck, Tony
2020-03-27 19:12       ` mark gross
2020-03-27 17:37     ` Josh Poimboeuf
2020-03-27 19:27       ` mark gross
2020-03-26  3:25 ` [MODERATED] Re: [PATCH 3/3] v4 more sampling fun 3 Josh Poimboeuf
2020-03-27 16:28   ` mark gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200319085040.GA3494118@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=speck@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).