On Wed, Jan 24, 2018 at 12:14:51PM +0000, David Woodhouse wrote:
> On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
> >
> > Typically tglx likes to use x86_match_cpu() for these things; see also
> > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> > errata").
>
> Ewww.
>
> static u32 hsx_deadline_rev(void)
> {
> switch (boot_cpu_data.x86_mask) {
> case 0x02: return 0x3a; /* EP */
> case 0x04: return 0x0f; /* EX */
> }
>
> return ~0U;
> }
> ...
> static const struct x86_cpu_id deadline_match[] = {
> DEADLINE_MODEL_MATCH_FUNC( INTEL_FAM6_HASWELL_X, hsx_deadline_rev),
> DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_BROADWELL_X, 0x0b000020),
> DEADLINE_MODEL_MATCH_FUNC( INTEL_FAM6_BROADWELL_XEON_D, bdx_deadline_rev),
> DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_X, 0x02000014),
> ...
>
> /*
> * Function pointers will have the MSB set due to address layout,
> * immediate revisions will not.
> */
> if ((long)m->driver_data < 0)
> rev = ((u32 (*)(void))(m->driver_data))();
> else
> rev = (u32)m->driver_data;
>
> EWWWW!
>
Yes :/
We could look at extending x86_cpu_id and x86_match_cpu with a stepping
option I suppose, but that might be lots of churn.
Thomas?
