On Wed, Jul 24, 2013 at 2:24 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx> wrote: > On Sat, Jul 20, 2013 at 9:27 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >> On Fri, Jul 19, 2013 at 02:04:47PM -0700, Luis R. Rodriguez wrote: >>> 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. > > OK, will do. > >>> 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. > > How about then just backporting like this then: > > #define DMI_EXACT_MATCH(a, b) DMI_MATCH(DMI_PRODUCT_NAME, "BACKPORT_IGNORE") > > It'd mean no #ifdef'ing code and at the same time making the run time > of the code of the mentioned patches skip. Yeah, I think as a solution for the backport tree that's a neat hack and would allow us to reuse the latest upstream drm/i915 code unchanged, without the risk of breaking some machines. Of course we'll miss a few quirk entries but the lack of such shouldn't ever cause regressions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
