On 05/23/2012 10:27 PM, Greg KH wrote:
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?
I don't think that. I know the value of writing and reading
documentation, and was acting in good faith. I didn't sufficiently
think through the whole version number thing before I wrote what I did.
My intention was to communicate that the patch is trivial and that it
should be backported to all kernel versions to which it applies cleanly.
I now realize that that was offloading the cognitive burden from me
onto you, which is definitely bad manners, but not the same as holding
crazy beliefs about documentation.
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 will do so in v3 of the patch. Thank you for the examples. Similar
examples in the docs, a public archive of the [email protected], or
earlier in this thread would have saved me a beer or two.
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?)
First, I apologize for the 'between the lines' snark. I now realize
that it was unreasonable to offload the burden of checking each -stable
version for obvious and subtle compatibility problems. This all *could*
have been avoided by me thinking a bit harder before I type, but some
other things that may help the next first-timer are:
* A public archive listed on http://vger.kernel.org/vger-lists.html .
Most of the other lists have them, and I used linux-ide's to great
effect when crafting the original upstream patch.
* Guidance in the docs about what your options are when specifying
kernel versions to apply to (e.g., "see http://www.kernel.org/ for a
list of active -stable kernel versions"), whether you need to explicitly
check all active versions before submitting, and most importantly what
the burden of proof is for proposing a patch be backported to a certain
version. Do you need to:
- Check out the latest point release and 'git apply --check' the patch?
- Build the kernel successfully?
- Run the kernel successfully? How many configurations/machines?
In my case, all I knew initially was that the patch would work on
3.2. Should I have said 'Please apply to 3.2-stable. I haven't been
able to test it on other versions.'? Should I say things like 'it will
apply and build on 3.3, and it will *probably* work just fine, but I'm
not in a position to boot test it right now because I don't have a spare
machine with the relevant hardware'?
Some of these questions might overlap with the general
burden-of-proof for proposing normal upstream patches, and may be better
answered in other docs, but submitting -stable patches might be a bit
different because, depending on the nature of the patch. the difficulty
of testing a patch may be multiplied by the number of active versions.
Thanks,
Matt
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
