On Mon, Jan 12, 2015 at 6:43 PM, Luis Henriques
<luis.henriques@xxxxxxxxxxxxx> wrote:
> On Mon, Jan 12, 2015 at 06:20:22PM +0100, Daniel Vetter wrote:
>> On Sun, Jan 11, 2015 at 10:49 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
>> > On Mon, 2014-12-15 at 14:24 +0000, Luis Henriques wrote:
>> >> 3.16.7-ckt3 -stable review patch. If anyone has any objections, please let me know.
>> >>
>> >> ------------------
>> >>
>> >> From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>> >>
>> >> commit f96de58fc7e7d3d717c7c63975c3b896c906b5e3 upstream.
>> >>
>> >> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>> >> Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx>
>> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>> >> Signed-off-by: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
>> >
>> > Should this also be applied to any older stable branches?
>> >
>> > i915_kick_out_firmware_fb() was introduced in 3.6 and it has always been
>> > possible for the alloc_apertures() call to fail.
>> >
>> > remove_conflicting_framebuffers() has returned an error code since 3.14
>> > (but could silently fail before then!) so this should be applicable to
>> > the 3.14 stable branch too.
>>
>> tbh I don't know why this patch ended up in a stable kernel, at least
>> I didn't find anything where we (drm/i915 maintainers) marked it as
>> such. And there's no bugzilla references added either. Imo the patch
>> doesn't qualify for stable (it's not a real-world bug afaik).
>
> You're right, this patch was not tagged for stable.
>
> While applying 0485c9dc24ec ("drm/i915: Kick fbdev before vgacon") to
> the 3.16 kernel, I found that cherry-picking f96de58fc7e7 would make
> it apply cleanly and it didn't shock me to have it in a stable kernel.
> That's why I applied it for release 3.16.7-ckt3. I guess I should
> have added a note in the commit text justifying its presence.
Ah makes sense. Usually we try to tag cc: stable patches with their
depencies (and I looked for that but didn't find anything). As a rule
I only scan stable patches from Greg's kernels since there's way too
much going on (and this time around too much vacation and conferences
on top).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
