[MODERATED] Re: [PATCH 1/3] v4 more sampling fun 1

Greg KH <[email protected]> Thu, 19 Mar 2020 09:50:40 +0100
Newsgroups org.kernel.lore.historical-speck
Message-ID <[email protected]>
On Mon, Mar 16, 2020 at 05:56:27PM -0700, speck for mark gross wrote:
> From: mark gross <[email protected]>
> 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