On 2014/6/5 11:56, Greg Kroah-Hartman wrote: > On Fri, Apr 25, 2014 at 02:55:09PM +0800, Yijing Wang wrote: >> On 2014/4/10 6:27, Greg Kroah-Hartman wrote: >>> On Wed, Mar 12, 2014 at 02:59:44PM +0800, Yijing Wang wrote: >>>> Hi Greg, >>>> >>>> These are the part II commits that I've analized from the list of >>>> upstream commits that have been backported to 3.2 but missing from 3.4. >>>> >>>> For the 17 commits, >>>> - 4 commits were marked for stable but can't be applied cleanly to >>>> 3.4.x. >>>> - 11 commits have no stable tag. I've found out why they were backported >>>> to 3.2.x, and I'm sure they should be applied to 3.4.x. >>>> - 2 commits dropped, because it fix a problem, but be reverted later. >>>> >>>> Please cherry-pick these commits from 3.2.x: >>>> 01d35d12e9a7 HID: logitech: don't use stack based dj_report structures >>> >>> That patch didn't apply at all :( >> >> Hi Greg, >> Sorry for the late reply. >> >> I tested this in my platform, and it can be applied ok. >> >> Current linux-3.4.y branch is in version 3.4.87. >> >> [yijing@localhost stable]$ git branch >> linux-3.2.y >> * linux-3.4.y >> master >> [yijing@localhost stable]$ git cherry-pick 01d35d12e9a7 >> warning: too many files (created: 1954 deleted: 1199), skipping inexact rename detection >> Finished one cherry-pick. >> [linux-3.4.y 80b2238] HID: logitech: don't use stack based dj_report structures >> Author: Marc Dionne <marc.c.dionne@xxxxxxxxx> >> 1 files changed, 24 insertions(+), 14 deletions(-) >> >> Something I missed ? >> >> So can you try it again ? > > I tried it again and it turns out that git is smarter than patch/diff > and quilt. There is an extra line between the functions so quilt (which > is what I use to manage stable patches) rejects the patch. I've fixed > it up by hand now, but I recommend you to use quilt when porting patches > to make sure that something like this doesn't happen again. Ok, thanks! > > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html