From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV Date: Fri, 17 Nov 2017 13:59:59 +0100 Message-ID: <20171117125959.GA29420@kroah.com> References: <20171115024521.5884-1-alexander.levin@verizon.com> <20171115024521.5884-36-alexander.levin@verizon.com> <20171115110805.GX10981@intel.com> <20171115164451.ogl3ku6qr3cfnbk7@sasha-lappy> <20171115170320.GK10981@intel.com> <87bmk15em2.fsf@intel.com> <20171117124123.GB24300@kroah.com> <20171117125343.GF10981@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20171117125343.GF10981@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , alexander.levin@verizon.com, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBOb3YgMTcsIDIwMTcgYXQgMDI6NTM6NDNQTSArMDIwMCwgVmlsbGUgU3lyasOkbMOk IHdyb3RlOgo+IE9uIEZyaSwgTm92IDE3LCAyMDE3IGF0IDAxOjQxOjIzUE0gKzAxMDAsIEdyZWcg S0ggd3JvdGU6Cj4gPiBPbiBGcmksIE5vdiAxNywgMjAxNyBhdCAwMToyODowNVBNICswMjAwLCBK YW5pIE5pa3VsYSB3cm90ZToKPiA+ID4gCj4gPiA+IENjOiBHcmVnCj4gPiA+IAo+ID4gPiBPbiBX ZWQsIDE1IE5vdiAyMDE3LCBWaWxsZSBTeXJqw6Rsw6QgPHZpbGxlLnN5cmphbGFAbGludXguaW50 ZWwuY29tPiB3cm90ZToKPiA+ID4gPiBPbiBXZWQsIE5vdiAxNSwgMjAxNyBhdCAwNDo0NDo1NFBN ICswMDAwLCBhbGV4YW5kZXIubGV2aW5AdmVyaXpvbi5jb20gd3JvdGU6Cj4gPiA+ID4+IE9uIFdl ZCwgTm92IDE1LCAyMDE3IGF0IDAxOjA4OjA1UE0gKzAyMDAsIFZpbGxlIFN5cmrDpGzDpCB3cm90 ZToKPiA+ID4gPj4gPk9uIFdlZCwgTm92IDE1LCAyMDE3IGF0IDAyOjQ1OjQzQU0gKzAwMDAsIGFs ZXhhbmRlci5sZXZpbkB2ZXJpem9uLmNvbSB3cm90ZToKPiA+ID4gPj4gPj4gRnJvbTogVmlsbGUg U3lyasODwqRsw4PCpCA8dmlsbGUuc3lyamFsYUBsaW51eC5pbnRlbC5jb20+Cj4gPiA+ID4+ID4+ Cj4gPiA+ID4+ID4+IFsgVXBzdHJlYW0gY29tbWl0IDFiZTRkMzc5M2Q1YTkzZGFkZGNkOWJlNjU3 YzQyOWIzOGFkNzUwYTMgXQo+ID4gPiA+PiA+Pgo+ID4gPiA+PiA+PiBUaGUgd2F0ZXJtYXJrIHNo b3VsZCBuZXZlciBleGNlZWQgdGhlIEZJRk8gc2l6ZSwgc28gd2UgbmVlZCB0bwo+ID4gPiA+PiA+ PiBjaGVjayBhZ2FpbnN0IHRoZSBjdXJyZW50IEZJRk8gc2l6ZSBpbnN0ZWFkIG9mIHRoZSB0aGVv cmV0aWNhbAo+ID4gPiA+PiA+PiBtYXhpbXVtIHdoZW4gd2UgY2xhbXAgdGhlIGxldmVsIDAgd2F0 ZXJtYXJrLgo+ID4gPiA+PiA+Pgo+ID4gPiA+PiA+PiBTaWduZWQtb2ZmLWJ5OiBWaWxsZSBTeXJq w4PCpGzDg8KkIDx2aWxsZS5zeXJqYWxhQGxpbnV4LmludGVsLmNvbT4KPiA+ID4gPj4gPj4gTGlu azogaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Bh dGNod29yay5mcmVlZGVza3RvcC5vcmdfcGF0Y2hfbXNnaWRfMTQ4MDM1NDYzNy0yRDE0MjA5LTJE NC0yRGdpdC0yRHNlbmQtMkRlbWFpbC0yRHZpbGxlLnN5cmphbGEtNDBsaW51eC5pbnRlbC5jb20m ZD1Ed0lEQXcmYz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9 YlV0YWFDOW1sQmlqNE9qRUdfRC1LUHVsXzMzNWF6WXpmQzRSamdvbW9ibyZtPWl1UHRVYXItVkVH Ykgxam1WSF9VVHI0QzAyWDhmbWpIVWZOWWl4LVljMFkmcz1oYV9GMHpQM0ExQXp0cDVTNWU2X2Jx ZGhpdXVQWGhuMGRSV1E1OHZ2M0lzJmU9Cj4gPiA+ID4+ID4+IFJldmlld2VkLWJ5OiBNYWFydGVu IExhbmtob3JzdCA8bWFhcnRlbi5sYW5raG9yc3RAbGludXguaW50ZWwuY29tPgo+ID4gPiA+PiA+ PiBTaWduZWQtb2ZmLWJ5OiBTYXNoYSBMZXZpbiA8YWxleGFuZGVyLmxldmluQHZlcml6b24uY29t Pgo+ID4gPiA+PiA+Cj4gPiA+ID4+ID5XaHkgYXJlIHRoZXNlIHBhdGNoZXMgYmVpbmcgcHJvcG9z ZWQgZm9yIHN0YWJsZT8gVGhleSdyZSBub3Qgc3RyYWlnaHQgdXAKPiA+ID4gPj4gPmZpeGVzIGZv ciBrbm93biBpc3N1ZXMsIGFuZCB0aGVyZSdzIGFsd2F5cyBhIGNoYW5jZSB0aGF0IHNvbWV0aGlu ZyB3aWxsCj4gPiA+ID4+ID5icmVhay4gV2hvIGlzIGRvaW5nIHRoZSBxYSBvbiB0aGlzPwo+ID4g PiA+PiAKPiA+ID4gPj4gSGkgVmlsbGUsCj4gPiA+ID4+IAo+ID4gPiA+PiBUaGV5IHdlcmUgc2Vs ZWN0ZWQgYXV0b21hdGljYWxseSBhcyBwYXJ0IG9mIGEgbmV3IHByb2Nlc3Mgd2UncmUgdHJ5aW5n Cj4gPiA+ID4+IG91dC4gSWYgeW91IGRpc2FncmVlIHdpdGggdGhlIHNlbGVjdGlvbiBJJ2QgYmUg aGFwcHkgdG8gZHJvcCBpdC4KPiA+ID4gPgo+ID4gPiA+IEhvdyBkb2VzIHRoYXQgYXV0b21hdGlj IHByb2Nlc3MgZGVjaWRlIHRoYXQgYSBwYXRjaCBzaG91bGQgYmUgYmFja3BvcnRlZD8KPiA+ID4g Pgo+ID4gPiA+IGRybSBhbmQgaTkxNSBhcmUgdmVyeSBmYXN0IG1vdmluZyB0YXJnZXRzIHNvIHVu aW50ZW5kZWQgc2lkZSBlZmZlY3RzIGZyb20KPiA+ID4gPiBiYWNrcG9ydGVkIHBhdGNoZXMgaXMg YSByZWFsIHBvc3NpYmlsaXR5LiBTbyBJIHdvdWxkIHJlY29tbWVuZCBhZ2FpbnN0Cj4gPiA+ID4g YmFja3BvcnRpbmcgYW55dGhpbmcgdGhhdCBpc24ndCBmaXhpbmcgYSByZWFsIGlzc3VlIGFmZmVj dGluZyB1c2Vycy4gV2UKPiA+ID4gPiBkbyB0cnkgdG8gYWRkIHRoZSBjYzpzdGFibGUgdG8gc3Vj aCBwYXRjaGVzLgo+ID4gPiAKPiA+ID4gQWdyZWVkLgo+ID4gPiAKPiA+ID4gRmlyc3QsIEkgdGhp bmsgYW4gYXV0b21hdGljIGJhY2twb3J0IHByb2Nlc3MgaXMgYWdhaW5zdCB0aGUgc3RhYmxlCj4g PiA+IGtlcm5lbCBydWxlcyAoZS5nLiAiSXQgbXVzdCBmaXggYSByZWFsIGJ1ZyB0aGF0IGJvdGhl cnMgcGVvcGxlIikuCj4gPiAKPiA+IEl0J3MgZmluZGluZyBsb3RzIG9mIGZpeGVzIHRoYXQgZGlk IGJvdGhlciBwZW9wbGUgZW5vdWdoIHRvIHN1Ym1pdCBhIGZpeAo+ID4gZm9yLgo+ID4gCj4gPiA+ IFNlY29uZCwgd2UgY2FuJ3QgYW5kIHdvbid0IHRha2UgYW55IHJlc3BvbnNpYmlsaXR5IGZvciBi YWNrcG9ydHMgd2UKPiA+ID4gZGlkbid0IGluZGljYXRlIHdpdGggQ2M6IHN0YWJsZSwgYSBGaXhl czogdGFnLCBvciBhIHNwZWNpZmljIGJhY2twb3J0Cj4gPiA+IHJlcXVlc3QuCj4gPiAKPiA+IE9r LCB5b3UgYWxsIGFyZSBhbHJlYWR5IHRvdGFsbHkgbWVzc2luZyB3aXRoIG15IG5vcm1hbCBzdGFi bGUgd29ya2Zsb3csCj4gPiBzbyBtaWdodCBhcyB3ZWxsIGp1c3QgdHJ1c3QgeW91IGFsbCBjb21w bGV0ZWx5LiAgU28gbGV0J3MganVzdCBvbmx5IHRha2UKPiA+IHBhdGNoZXMgdGhhdCB5b3UgYWxs IGRvIHNlbmQgbWUgaW4gdGhlIG5vcm1hbCB3YXkuICBJdCdzIGVhc3kgZm9yIFNhc2hhCj4gPiB0 byBmaWx0ZXIgb3V0IHRoZSBkcm0vaTkxNSBwYXRjaGVzIGZyb20gaGlzIHJlc3VsdHMuCj4gPiAK PiA+IElzIHRoYXQgb2s/Cj4gPiAKPiA+ID4gSWYgeW91IHRoaW5rIHRoZXJlJ3MgYSBjb21taXQg dGhhdCBzaG91bGQgYmUgYmFja3BvcnRlZCBhbmQgaXMga25vd24gdG8KPiA+ID4gZml4IGEgdXNl ciB2aXNpYmxlIGlzc3VlIChhcyBwZXIgdGhlIHN0YWJsZSBydWxlcyEpLCBwbGVhc2UgY2hlY2sg d2l0aAo+ID4gPiB1cyBmaXJzdC4KPiA+IAo+ID4gVW0sIHRoYXQgaXMgd2hhdCBoZSB3YXMgZG9p bmcgd2l0aCB0aGUgY2M6IG9mIHlvdSBhbGwgb24gdGhlIHBhdGNoCj4gPiBpdHNlbGYgdGhhdCBz dGFydGVkIHRoaXMgd2hvbGUgY29udmVyc2F0aW9uLi4uCj4gCj4gQW5kIHdoYXQgd2VyZSB0aGUg dXNlciB2aXNpYmxlIGlzc3VlcyBmaXhlZCBieSB0aG9zZSBiYWNrcG9ydHM/IFdlCj4gY2FuJ3Qg anVkZ2UgdGhlIHJpc2svYmVuZWZpdCByYXRpbyBvZiBhIGJhY2twb3J0IHdpdGhvdXQga25vd2lu ZyB3aGF0Cj4gaXMgc3VwcG9zZWRseSBiZWluZyBmaXhlZC4KCk9rIGZpbmUsIGlmIHlvdSBhbGwg ZG9uJ3Qgd2FudCBhbnkgcGF0Y2hlcyBhdXRvbWF0aWNhbGx5IHBpY2tlZCB1cCBhbmQKYmFja3Bv cnRlZCwgdGhhdCdzIHlvdXIgY2hvaWNlLCBqdXN0IGxldCB1cyBrbm93IGFuZCB3ZSB3aWxsIGFk ZCBpdCB0byBhCmJsYWNrbGlzdCBvciBzb21ldGhpbmcgdG8gcHJldmVudCBpdC4gIFlvdXIgZGV2 ZWxvcG1lbnQgcHJvY2VzcyBtdXN0IGJlCnNvIHBlcmZlY3QgdGhhdCBub3RoaW5nIGZhbGxzIHRo cm91Z2ggdGhlIGNyYWNrcyBhbmQgZm9yZ2V0cyB0byBnZXQKbWFya2VkIGZvciBzdGFibGUuLi4K CmdyZWcgay1oCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpo dHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933067AbdKQNAT (ORCPT ); Fri, 17 Nov 2017 08:00:19 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:56358 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933299AbdKQM7z (ORCPT ); Fri, 17 Nov 2017 07:59:55 -0500 Date: Fri, 17 Nov 2017 13:59:59 +0100 From: Greg KH To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: Jani Nikula , alexander.levin@verizon.com, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV Message-ID: <20171117125959.GA29420@kroah.com> References: <20171115024521.5884-1-alexander.levin@verizon.com> <20171115024521.5884-36-alexander.levin@verizon.com> <20171115110805.GX10981@intel.com> <20171115164451.ogl3ku6qr3cfnbk7@sasha-lappy> <20171115170320.GK10981@intel.com> <87bmk15em2.fsf@intel.com> <20171117124123.GB24300@kroah.com> <20171117125343.GF10981@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171117125343.GF10981@intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 17, 2017 at 02:53:43PM +0200, Ville Syrjälä wrote: > On Fri, Nov 17, 2017 at 01:41:23PM +0100, Greg KH wrote: > > On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote: > > > > > > Cc: Greg > > > > > > On Wed, 15 Nov 2017, Ville Syrjälä 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ä > > > >> >> > > > >> >> [ 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ä > > > >> >> 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 > > > >> >> Signed-off-by: Sasha Levin > > > >> > > > > >> >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... > > And what were the user visible issues fixed by those backports? We > can't judge the risk/benefit ratio of a backport without knowing what > is supposedly being fixed. Ok fine, if you all don't want any patches automatically picked up and backported, that's your choice, just let us know and we will add it to a blacklist or something to prevent it. Your development process must be so perfect that nothing falls through the cracks and forgets to get marked for stable... greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:56358 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933299AbdKQM7z (ORCPT ); Fri, 17 Nov 2017 07:59:55 -0500 Date: Fri, 17 Nov 2017 13:59:59 +0100 From: Greg KH To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: Jani Nikula , alexander.levin@verizon.com, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV Message-ID: <20171117125959.GA29420@kroah.com> References: <20171115024521.5884-1-alexander.levin@verizon.com> <20171115024521.5884-36-alexander.levin@verizon.com> <20171115110805.GX10981@intel.com> <20171115164451.ogl3ku6qr3cfnbk7@sasha-lappy> <20171115170320.GK10981@intel.com> <87bmk15em2.fsf@intel.com> <20171117124123.GB24300@kroah.com> <20171117125343.GF10981@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171117125343.GF10981@intel.com> Sender: stable-owner@vger.kernel.org List-ID: On Fri, Nov 17, 2017 at 02:53:43PM +0200, Ville Syrj�l� wrote: > On Fri, Nov 17, 2017 at 01:41:23PM +0100, Greg KH wrote: > > On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote: > > > > > > Cc: Greg > > > > > > On Wed, 15 Nov 2017, Ville Syrj�l� 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ä > > > >> >> > > > >> >> [ 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ä > > > >> >> 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 > > > >> >> Signed-off-by: Sasha Levin > > > >> > > > > >> >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... > > And what were the user visible issues fixed by those backports? We > can't judge the risk/benefit ratio of a backport without knowing what > is supposedly being fixed. Ok fine, if you all don't want any patches automatically picked up and backported, that's your choice, just let us know and we will add it to a blacklist or something to prevent it. Your development process must be so perfect that nothing falls through the cracks and forgets to get marked for stable... greg k-h