On Fri, Jul 19, 2013 at 02:04:47PM -0700, Luis R. Rodriguez wrote:
> On Fri, Jul 19, 2013 at 5:31 AM, Chris Wilson <[email protected]>
> wrote:
> > On Fri, Jul 19, 2013 at 05:00:06AM -0700, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <[email protected]>
> >>
> >> struct dmi_strmatch was modified on v3.11 with a
> >> exact_match member. The DMI_EXACT_MATCH() macro was
> >> added as a mod version of DMI_MATCH() to account for
> >> dmi strings that look closely like each other. An
> >> example is D510MO Vs D510MOV.
> >>
> >> Since exact_match is is not available on older kernels
> >> we can't use it and must revert to the old DMI_MATCH().
> >> Addressing the desired behaviour will require a separate
> >> change to deal with addressing the difference
> >> in the behaviour.
> >
> > If you choose not to backport DMI_EXACT_MATCH, then don't backport the
> > two fixes that depend upon it.
>
> Which ones? These two?
>
> dcf6d294830d46b0e6901477fb4bf455281d90c8 - drm/i915: quirk away
> phantom LVDS on Intel's D525MW mainboard
> e5614f0c2d0f4d7f0b8ef745d34593baf2c5dbf8 - drm/i915: quirk away
> phantom LVDS on Intel's D510MO mainboard
Yes.
> Just #ifdef over these for older kernels ifndef DMI_EXACT_MATCH ?
>
> > Is there a blocker for not backporting the DMI_EXACT_MATCH feature?
>
> I'm so glad you asked. DMI_EXACT_MATCH uses struct dmi_strmatch's new
> member exact_match:
>
> @@ -456,7 +456,8 @@ enum dmi_field {
> };
>
> struct dmi_strmatch {
> - unsigned char slot;
> + unsigned char slot:7;
> + unsigned char exact_match:1;
> char substr[79];
> };
>
> Prior to 5017b285 we only had slot so to use DMI_EXACT_MATCH with its
> intent we'd have to do something like slot |= 1 if its called. This
> however assumes though that older code has the sanity check as changed
> in 5017b285 on drivers/firmware/dmi_scan.c. dmi_scan.o gets linked
> with CONFIG_DMI. At least for x86 that gets objects sprinkled on
> arch/x86/, but more importantly CONFIG_DMI is bool. I've argued how I
> envision us being able to backport core components before (see
> 0935deab for the hint) but as it is right now we can't. We only
> backport things we can throw in as modular.
>
> Please let me know if you see any other way.
An alternative ugly hack would be to encode some metadata into the
search string. I am a bit wary of simply converting the DMI_EXACT_MATCH
back into DMI_MATCH because that introduces a regression into working
machines if we blithely backport fixes like the two above. I'd rather
have the compile failure.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe backports" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
