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: stable@xxxxxxxxxxxxxxx > >>>> Reported-and-tested-by: Vincent Gerris <vgerris@xxxxxxxxx> > >>>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > >>> > >>> 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 linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
