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. I wasn't a
subscriber to the list previously, and there are no archives listed on
the website http://vger.kernel.org/vger-lists.html#stable , so I
couldn't easily find examples to go on. I tried looking at -stable
changelogs (e.g.
http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.18 ), but most
of the ones that mention -stable at all either don't mention a version
number, or pertain to a specific regression where the relevant version
number is clear.
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.
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.
-Matt
I hate it when I write things that people just don't even read, even
when they quote it back to me. Why do I even write it in the first
place?
It's enough to drive someone to drink, so, you owe me a beer.
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
