Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-04-12 Thread Greg KH
On Wed, Apr 12, 2017 at 02:48:55PM +0200, Greg KH wrote: > On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote: > > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH > > wrote: > > > Why don't the maintainers know which tree to put them in when they are > > > submitted? As an example, if I get

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-04-12 Thread Greg KH
On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote: > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH wrote: > > Why don't the maintainers know which tree to put them in when they are > > submitted? As an example, if I get a patch that needs to go to Linus, I > > put it in my usb-linus branc

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-16 Thread Greg KH
On Thu, Mar 16, 2017 at 04:40:01PM +0200, Jani Nikula wrote: > On Thu, 16 Mar 2017, Greg KH wrote: > > And again, you all are the only ones that have this issue. You might > > find a handfull of patches for stable that come in twice in the rest of > > the kernel, but your "little" driver dwarfs t

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-16 Thread Jani Nikula
On Thu, 16 Mar 2017, Greg KH wrote: > And again, you all are the only ones that have this issue. You might > find a handfull of patches for stable that come in twice in the rest of > the kernel, but your "little" driver dwarfs that by an order of > magnitude. I really think you are doing it wron

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-16 Thread Greg KH
On Thu, Mar 16, 2017 at 08:38:30AM +0100, Daniel Vetter wrote: > Hi Greg, > > On Mon, Mar 13, 2017 at 07:40:50AM +0100, Daniel Vetter wrote: > > On Sun, Mar 12, 2017 at 11:01 PM, Greg KH > > wrote: > > > So if a commit says "cherry-pick", I guess I can always assume it's safe > > > to add, right

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-16 Thread Daniel Vetter
Hi Greg, On Mon, Mar 13, 2017 at 07:40:50AM +0100, Daniel Vetter wrote: > On Sun, Mar 12, 2017 at 11:01 PM, Greg KH wrote: > > So if a commit says "cherry-pick", I guess I can always assume it's safe > > to add, right? If not, _then_ I have to run the "search backwards" > > logic, right? > > > >

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-13 Thread Jani Nikula
On Mon, 13 Mar 2017, Daniel Vetter wrote: > Our cherry-pick sha1 work exactly like yours: They don't make sense > when you only look at the tree a patch has been cherry-picked _to_, > since they're the sha1 from the tree they've been cherry-picked > _from_. When you clone a fresh copy of your stab

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-12 Thread Daniel Vetter
On Sun, Mar 12, 2017 at 10:52 PM, Greg KH wrote: > Why don't the maintainers know which tree to put them in when they are > submitted? As an example, if I get a patch that needs to go to Linus, I > put it in my usb-linus branch, and when it hits a -rc release, I then > merge that -rc back into my

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-12 Thread Daniel Vetter
On Sun, Mar 12, 2017 at 11:01 PM, Greg KH wrote: >> So I blame this on flight level 350, but we discussed this at kernel >> summit. Every patch we cherry-pick over comes with a "cherry-picked from >> $sha1" line, as long as you ignore any such sha1 as duplicate you won't >> see the same patch twic

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-12 Thread Greg KH
On Sun, Mar 12, 2017 at 09:46:21PM +0100, Daniel Vetter wrote: > On Sun, Mar 12, 2017 at 08:44:40PM +0100, Greg KH wrote: > > Hi Daniel and Jani and other members of the i915-commit-cabal, > > > > I've mentioned this a few times to Daniel in the past (like at the last > > kernel summit), but the w

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-03-12 Thread Daniel Vetter
On Sun, Mar 12, 2017 at 08:44:40PM +0100, Greg KH wrote: > Hi Daniel and Jani and other members of the i915-commit-cabal, > > I've mentioned this a few times to Daniel in the past (like at the last > kernel summit), but the way you all are handling the tagging of patches > for inclusion in stable