lkml.org 
[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV
On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
>
> Cc: Greg
>
> On Wed, 15 Nov 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
> >> On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
> >> >On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
> >> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >>
> >> >> [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
> >> >>
> >> >> The watermark should never exceed the FIFO size, so we need to
> >> >> check against the current FIFO size instead of the theoretical
> >> >> maximum when we clamp the level 0 watermark.
> >> >>
> >> >> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >> Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >> >> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
> >> >
> >> >Why are these patches being proposed for stable? They're not straight up
> >> >fixes for known issues, and there's always a chance that something will
> >> >break. Who is doing the qa on this?
> >>
> >> Hi Ville,
> >>
> >> They were selected automatically as part of a new process we're trying
> >> out. If you disagree with the selection I'd be happy to drop it.
> >
> > How does that automatic process decide that a patch should be backported?
> >
> > drm and i915 are very fast moving targets so unintended side effects from
> > backported patches is a real possibility. So I would recommend against
> > backporting anything that isn't fixing a real issue affecting users. We
> > do try to add the cc:stable to such patches.
>
> Agreed.
>
> First, I think an automatic backport process is against the stable
> kernel rules (e.g. "It must fix a real bug that bothers people").

It's finding lots of fixes that did bother people enough to submit a fix
for.

> Second, we can't and won't take any responsibility for backports we
> didn't indicate with Cc: stable, a Fixes: tag, or a specific backport
> request.

Ok, you all are already totally messing with my normal stable workflow,
so might as well just trust you all completely. So let's just only take
patches that you all do send me in the normal way. It's easy for Sasha
to filter out the drm/i915 patches from his results.

Is that ok?

> If you think there's a commit that should be backported and is known to
> fix a user visible issue (as per the stable rules!), please check with
> us first.

Um, that is what he was doing with the cc: of you all on the patch
itself that started this whole conversation...

{sigh}

greg k-h

\
 
 \ /
  Last update: 2017-11-17 17:19    [W:0.174 / U:5.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site