[Intel-gfx] [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote:
> On Fri, 17 Nov 2017, Greg KH <gregkh at linuxfoundation.org> wrote:
> > 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 at linux.intel.com> wrote:
> >> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin at 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 at verizon.com wrote:
> >> >> >> From: Ville Syrjälä <ville.syrjala at 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 at 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 at linux.intel.com>
> >> >> >> Signed-off-by: Sasha Levin <alexander.levin at 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.
> 
> I still have no idea how this autoselect picks up patches that do *not*
> have cc: stable nor Fixes: from us. What information do you have that we
> don't for making that call?

I'll let Sasha describe how he's doing this, but in the end, does it
really matter _how_ it is done, vs. the fact that it seems to at least
one human reviewer that this is a patch that _should_ be included based
on the changelog text and the code patch?

By having this review process that Sasha is providing, he's saying
"Here's a patch that I think might be good for stable, do you object?"

If you do, great, no harm done, all is fine, the patch is dropped.  If
you don't object, just ignore the email and the patch gets merged.

If you don't want any of this to happen for your subsystem at all, then
also fine, just let us know and we will ignore it entirely.

thanks,

greg k-h