Re: WTF: patch "[PATCH] drm/i915: Fix init_clock_gating for resume" was seriously submitted to be applied to the 4.14-stable tree?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 04, 2017 at 07:07:06PM +0000, Greg KH wrote:
> On Mon, Dec 04, 2017 at 10:45:50AM -0800, Rodrigo Vivi wrote:
> > 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)
> 
> This patch got rejected and got a FAILED email

Oh I see.

> 
> 
> >   - 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 did not apply, and got a FAILED email response.
> 
> >   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?
> 
> Nope, not much you can do about it failing :)
> 
> > - I wonder if 4.9 stable should also have all of them as well. Should it?
> 
> That's up to you all, not me.

yeap!

> 
> > 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?
> 
> Yes that would be great.
> 
> > - 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?
> 
> First off, the WTF is just an email script,

I imagined that, but I wasn't sure...

> don't take it personally.

I never take personally ;)

I just jumped in and asked to understand the big picture and see if there
was something we could improve here.

> 
> Second, I sent it because it referred to a patch that was not in 4.14,
> and was not in any stable queue.  I did not catch that I had already
> rejected it, as I really don't have a way to do that at all.

All makes sense now! Also I'm glad this is not a frequent case.

> 
> So all is fine, just backport the changes and send them to me and I'll
> be glad to queue them up.

Cool,

Thanks,
Rodrigo.

> 
> thanks,
> 
> greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]