On Friday, May 02, 2014 11:02:54 AM Hans de Goede wrote: > Hi, > > On 05/01/2014 10:10 PM, Rafael J. Wysocki wrote: > > On Thursday, May 01, 2014 12:38:28 PM Hans de Goede wrote: > >> Hi, > >> > >> On 04/30/2014 09:52 PM, Rafael J. Wysocki wrote: > >>> On Wednesday, April 30, 2014 03:37:21 PM Hans de Goede wrote: > >>>> This fixes the backlight control not working. > >>>> > >>>> Cc: [email protected] > >>>> Reported-and-tested-by: Vincent Gerris <[email protected]> > >>>> Signed-off-by: Hans de Goede <[email protected]> > >>> > >>> Sorry, this conflicts with commit 170269a9d3c0 (ACPI / video: Default to > >>> using > >>> native backlight control on Windows 8 systems) in linux-next, so I'm not > >>> going > >>> to apply it. > >> > >> I strongly disagree, rejecting bug-fixes which conflict with more rigorous > >> (and dangerous) fixes -next, purely because the conflict with something > >> -next > >> is not a good reason. TBH I find it a complete non reason to reject these > >> fixes. > >> > >>> If you wanted to have this stuff in 3.15, there was a plenty of time to > >>> submit > >>> it earlier. > >> > >> Heh, that assumes I was aware of this particular model needing this quirk > >> earlier, > >> while I actually got the first report of it not working from Vincent on > >> April 26th, > >> and got confirmation that the quirk fixes it on April 29th. I would say > >> that 1 day > >> turn around time between getting the confirmation and sending the patch is > >> not bad > >> at all. > >> > >> I really believe it is important to get the quirk for this model (and > >> others) into > >> 3.15, here us my decision tree leading to this: > >> > >> -Do we want to fix these brightness issues -> Yes > >> -Do we expect our users to wait for 6 months for an upstream fix + many > >> more months > >> for the fixed kernel to hit distros -> No > >> -So we want to backport these fixes to stable -> Yes > >> -Is the proposed fix for 3.16 acceptable for stable -> No (too high change > >> of > >> regressions) > > > > OK, this is a good argument. > > > >> Conclusion: we want quirks for models known to need quirks added to 3.15 > >> and > >> backported to the various stable series. > >> > >> I actually want to go as far as to claim that once 3.15 is released we > >> will want > >> to add quirks to 3.15.x, breaking the every fix must be upstream rule for > >> the stable > >> series. But lets safe that discussion for later. > > > > Well, there's a way out of this. Instead of doing commit 170269a9d3c0 as > > is, we > > can just switch the default without removing the blacklist just yet. And > > remove > > the blacklist one we are reasonably confident that the new default actually > > works. > > > > In which case I'd go for your original series (along with the RFC moving > > stuff > > out of blacklist.c to the video.c blacklist) with a replacement of commit > > 170269a9d3c0 that will simply flip the default. > > > > Does this make sense to you? > > Yes that seems like a good solution, thanks! > > I'll rebase and resend my RFC for moving the models from blacklist.c to > video.c as non > RFC. > > Who is going to do the only flip the default version of 170269a9d3c0 ?
That would be either you or me I guess. :-) -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
