On Mon, Dec 04, 2017 at 01:47:14PM +0000, Greg KH wrote: > On Mon, Dec 04, 2017 at 03:41:18PM +0200, Ville Syrjälä wrote: > > On Mon, Dec 04, 2017 at 02:13:00PM +0100, Greg KH wrote: > > > On Mon, Dec 04, 2017 at 02:54:31PM +0200, Ville Syrjälä wrote: > > > > On Mon, Dec 04, 2017 at 01:36:08PM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > > The patch below was submitted to be applied to the 4.14-stable tree. > > > > > > > > > > I fail to see how this patch meets the stable kernel rules as found at > > > > > Documentation/process/stable-kernel-rules.rst. > > > > > > > > It fixes a regression. Why do you think it's not suitable for stable? > > > > > > Because: > > > > > > > > I could be totally wrong, and if so, please respond to > > > > > <stable@xxxxxxxxxxxxxxx> and let me know why this patch should be > > > > > applied. Otherwise, it is now dropped from my patch queues, never to be > > > > > seen again. > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > > > > > > > ------------------ original commit in Linus's tree ------------------ > > > > > > > > > > >From 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001 > > > > > From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > Date: Thu, 16 Nov 2017 18:02:15 +0200 > > > > > Subject: [PATCH] drm/i915: Fix init_clock_gating for resume > > > > > MIME-Version: 1.0 > > > > > Content-Type: text/plain; charset=UTF-8 > > > > > Content-Transfer-Encoding: 8bit > > > > > > > > > > Moving the init_clock_gating() call from intel_modeset_init_hw() to > > > > > intel_modeset_gem_init() had an unintended effect of not applying > > > > > some workarounds on resume. This, for example, cause some kind of > > > > > corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS > > > > > screen after hibernation. Fix the problem by explicitly calling > > > > > init_clock_gating() from the resume path. > > > > > > > > > > I really hope this doesn't break something else again. At least > > > > > the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549 > > > > > didn't make a comeback, even after a hibernate cycle. > > > > > > > > > > v2: Reorder the init_clock_gating vs. modeset_init_hw to match > > > > > the display reset path (Rodrigo) > > > > > > > > > > Cc: stable@xxxxxxxxxxxxxxx > > > > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > > Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was") > > > > > > $ git describe --contains 6ac43272768c > > > v4.15-rc1~19^2~13^2~1 > > > > > > How is this a 4.14 regression? > > > > commit 6ac43272768ca901daac4076a66c2c4e3c7b9321 > > Author: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Date: Wed Nov 8 15:35:55 2017 +0200 > > > > drm/i915: Move init_clock_gating() back to where it was > > ... > > Cc: stable@xxxxxxxxxxxxxxx > > > > > > So 4.14 is going to break once that gets backported. > > Ok, then the backporter should include both of those, as this one did > not apply at all to the tree :( Hi Greg, I have few questions here around this history. Please help me to understand what is going on so we can improve the process and make sure this doesn't happen again. I'm also bringing Daniel because he mentioned you have removed us from a blacklist and I don't know details about the history of that or on any details that could make you angry in the past with our fixes. In summary: - This patch here 3572f04c69ed ("drm/i915: Fix init_clock_gating\ for resume") - Fixes 6ac43272768c (part of 4.15-rc2 now) - Which fixes b7048ea12fbb (released first on v4.11) - which fixes ed4a6a7ca853 (introduced on 4.7) My questions: - What happened with 6ac43272768c that wasn't considered for the 4.14 stable? It has the same Cc:stable tag as the last patch. Is there anything we should had done differently to make sure this patch was got by you on 4.14 before the second one blowing up your scripts? - I wonder if 4.9 stable should also have all of them as well. Should it? Maybe the should part of it is more for Ville to tell us actually. But if so the next question would be what process should we follow for that? Just backport those 3 to 4.9.66 and test here and send to stable@ ml? - What was the reason that you used the "WTF - never to be seen again" tone instead of the regular "FAILED - if someone wants to apply..."? Or in other words, what can we do to improve and not make you angry again? Thanks, Rodrigo.