On Wed, May 23, 2012 at 10:12:00PM -0700, Matt Johnson wrote: > On 05/23/2012 09:48 PM, Greg KH wrote: > >On Wed, May 23, 2012 at 11:30:01PM -0500, Matt Johnson wrote: > >>On 05/23/2012 11:13 PM, Greg KH wrote: > >>>On Wed, May 23, 2012 at 10:23:13PM -0500, Matt Johnson wrote: > >>>> From 642d89252201c4155fc3946bf9cdea409e5d263e Mon Sep 17 00:00:00 2001 > >>>>From: Matt Johnson<[email protected]> > >>>>Date: Fri, 27 Apr 2012 01:42:30 -0500 > >>>>Subject: [PATCH] ahci: Detect Marvell 88SE9172 SATA controller > >>>> > >>>>Upstream commit 642d89252201c4155fc3946bf9cdea409e5d263e. > >>>>Adds a new, previously unrecognized device, so please apply to all > >>>>relevant kernel versions. > >>>> > >>>>The Marvell 88SE9172 SATA controller (PCI ID 1b4b 917a) already worked > >>>>once it was detected, but was missing an ahci_pci_tbl entry. > >>>> > >>>>Boot tested on a Gigabyte Z68X-UD3H-B3 motherboard. > >>>> > >>>>Signed-off-by: Matt Johnson<[email protected]> > >>>>Signed-off-by: Jeff Garzik<[email protected]> > >>>>--- > >>>> drivers/ata/ahci.c | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>> > >>> > >>><formletter> > >>> > >>>This is not the correct way to submit patches for inclusion in the > >>>stable kernel tree. Please read Documentation/stable_kernel_rules.txt > >>>for how to do this properly. > >>> > >>></formletter> > >> > >>Hi Greg, > >>I did read the docs, and attempted to follow them. My problem in > >>this case is that I didn't know about the 'Cc: stable..' procedure > >>until after the patch had already been upstreamed. I thus attempted > >>to follow this part of the guideline: > >> > >> - Send the patch, after verifying that it follows the above rules, to > >> [email protected]. You must note the upstream commit ID in the > >> changelog of your submission, as well as the kernel version you wish > >> it to be applied to. > >> > >>Are you saying that the patch itself is incorrect in some other way, > >>or pointing out (correctly) that future patches should use the 'Cc: > >>stable..' path? If the former, please elaborate and I'll be happy > >>to fix it. If the latter, acknowledged; won't happen again :) > > > >How about the fact that you really did not follow what that paragraph > >above that you quoted asked you to do? > > > > The upstream commit ID is there, so I'll assume you want me to be > more specific about which versions I'd like it to apply to.
Exactly, why would the sentance ask you do to just that if it didn't matter? Again, do you think we write things for no good reason? > AFAICT, stable_kernel_rules.txt doesn't prescribe what kernel > versions a new-device-ID patch should be apply to, so I worded it > the way I did in hopes that somebody more knowledgeable could use > their judgement and apply the usual policy, whatever that is, about > applying new-device-ID patches as far back as makes sense. For my > personal purposes, just 3.2 would be fine, but it would do others a > favor to backport the patch wherever it is straightforward to do so. > I did not know that saying something like the above was > unacceptable, even after reading the docs; now I do, lesson learned. You can say something like "apply to all stable kernels" or "this will only work on 3.3 for this reason". > I'll resub with a more explicit version number. My apologies in > advance if I still haven't read between the lines correctly; I guess > that'd make it 2 beers. There was no "between the lines", the information needed was right there, in the line itself. How much more specific could we have been (not a rhetorical question, can we be better here?) greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
