| Message ID | 1346303687-7795-1-git-send-email-andrew@lunn.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Aug 30, 2012 at 07:14:47AM +0200, Andrew Lunn wrote: > Tools like kisskb are good at finding build regressions in the kernel > sources. However, regressions in the DT desscriptions are not found, > because generally these build systems don't build the DT binary blobs. > > Extend the ARM all target to build all enabled DTB files. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Jason Cooper <jason@lakedaemon.net> I've CC'd stable to see if they want to pick this up. It does depend on having dtc built. A patch already exists to build dtc on demand, but I'm not sure if it has made it into mainline yet. It may be in Russell's queue. thx, Jason. > --- > v2: * in the help test > Only invoke dtbs if CONFIGUSE_OF=y > > arch/arm/Makefile | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 30eae87..0457ef4 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -268,7 +268,12 @@ else > KBUILD_IMAGE := zImage > endif > > -all: $(KBUILD_IMAGE) > +# Build the DT binary blobs if we have OF configured > +ifeq ($(CONFIG_USE_OF),y) > +KBUILD_DTBS := dtbs > +endif > + > +all: $(KBUILD_IMAGE) $(KBUILD_DTBS) > > boot := arch/arm/boot > > @@ -306,7 +311,7 @@ define archhelp > echo ' uImage - U-Boot wrapped zImage' > echo ' bootpImage - Combined zImage and initial RAM disk' > echo ' (supply initrd image via make variable INITRD=<path>)' > - echo ' dtbs - Build device tree blobs for enabled boards' > + echo '* dtbs - Build device tree blobs for enabled boards' > echo ' install - Install uncompressed kernel' > echo ' zinstall - Install compressed kernel' > echo ' uinstall - Install U-Boot wrapped compressed kernel' > -- > 1.7.10.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > On Thu, Aug 30, 2012 at 07:14:47AM +0200, Andrew Lunn wrote: > > Tools like kisskb are good at finding build regressions in the kernel > > sources. However, regressions in the DT desscriptions are not found, > > because generally these build systems don't build the DT binary blobs. > > > > Extend the ARM all target to build all enabled DTB files. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > Acked-by: Jason Cooper <jason@lakedaemon.net> > > I've CC'd stable to see if they want to pick this up. That's not how stable works - and you'll probably receive a standard form whinge from them about that. Please read up on the submission requirements to the stable kernel trees. > It does depend on > having dtc built. A patch already exists to build dtc on demand, but > I'm not sure if it has made it into mainline yet. It may be in > Russell's queue. At the moment, the only stuff I have outstanding for -rc is: 36418c5 ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM df547e0 ARM: 7503/1: mm: only flush both pmd entries for classic MMU ae3790b ARM: 7502/1: contextidr: avoid using bfi instruction during notifier dbece45 ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores d968d2b ARM: 7497/1: hw_breakpoint: allow single-byte watchpoints on all addressbf88011 ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint accessa849088 ARM: Fix ioremap() of address zero I have nothing queued for dtc building, and there's no sign of anything new in the patch system.
On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > On Thu, Aug 30, 2012 at 07:14:47AM +0200, Andrew Lunn wrote: > > Tools like kisskb are good at finding build regressions in the kernel > > sources. However, regressions in the DT desscriptions are not found, > > because generally these build systems don't build the DT binary blobs. > > > > Extend the ARM all target to build all enabled DTB files. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > Acked-by: Jason Cooper <jason@lakedaemon.net> > > I've CC'd stable to see if they want to pick this up. It does depend on > having dtc built. A patch already exists to build dtc on demand, but > I'm not sure if it has made it into mainline yet. It may be in > Russell's queue. <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>
On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > > I've CC'd stable to see if they want to pick this up. > > That's not how stable works - and you'll probably receive a standard form > whinge from them about that. Please read up on the submission requirements > to the stable kernel trees. Ah, thanks. usually, I just add the Cc: line for fixes I send to arm-soc. Since this patch affects more than just kirkwood/marvell, I didn't feel it was appropriate to pull it in through my tree. > > It does depend on having dtc built. A patch already exists to build > > dtc on demand, but I'm not sure if it has made it into mainline yet. > > It may be in Russell's queue. > > At the moment, the only stuff I have outstanding for -rc is: > > 36418c5 ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM > df547e0 ARM: 7503/1: mm: only flush both pmd entries for classic MMU > ae3790b ARM: 7502/1: contextidr: avoid using bfi instruction during notifier > dbece45 ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores > d968d2b ARM: 7497/1: hw_breakpoint: allow single-byte watchpoints on all address > bf88011 ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access > a849088 ARM: Fix ioremap() of address zero > > I have nothing queued for dtc building, and there's no sign of anything > new in the patch system. What I'm referring to is here: http://lkml.org/lkml/2012/8/28/257 I submitted a patch six months ago for the exact same thing and was informed that others already had a pending patch in your queue for it. However, I can't for the life of me locate the thread atm. I remember it because it was the first patch I did that needed to go into your queue instead of through arm-soc. Obviously, I did something horribly wrong. ;-) thx, Jason.
On Thu, Aug 30, 2012 at 02:37:11PM -0400, Jason Cooper wrote: > On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > > > I've CC'd stable to see if they want to pick this up. > > > > That's not how stable works - and you'll probably receive a standard form > > whinge from them about that. Please read up on the submission requirements > > to the stable kernel trees. > > Ah, thanks. usually, I just add the Cc: line for fixes I send to > arm-soc. Since this patch affects more than just kirkwood/marvell, I > didn't feel it was appropriate to pull it in through my tree. Yes, you put the Cc: line in the commit, but you don't actually send it to that address. The only time that you do mail that address is when the commit is _in_ mainline and it doesn't have the Cc: tag or the stable team haven't picked it up. > I submitted a patch six months ago for the exact same thing and was > informed that others already had a pending patch in your queue for it. > However, I can't for the life of me locate the thread atm. I remember > it because it was the first patch I did that needed to go into your > queue instead of through arm-soc. Obviously, I did something horribly > wrong. ;-) I don't see anything in there for it - I tried searching for patches containing 'dtbs' and the latest one it found was 7152/1 on 8th November. I also see no notifications from the patch system for a patch from you...
On Thu, Aug 30, 2012 at 08:14:12PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 30, 2012 at 02:37:11PM -0400, Jason Cooper wrote: > > On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > > > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: ... > > I submitted a patch six months ago for the exact same thing and was > > informed that others already had a pending patch in your queue for it. > > However, I can't for the life of me locate the thread atm. I remember > > it because it was the first patch I did that needed to go into your > > queue instead of through arm-soc. Obviously, I did something horribly > > wrong. ;-) > > I don't see anything in there for it - I tried searching for patches > containing 'dtbs' and the latest one it found was 7152/1 on 8th > November. I also see no notifications from the patch system for a > patch from you... I should have been more clear, I sent it to lakml, was told to send it to your queue, and then I was told there was already a patch by someone else in your queue. So, I dropped mine from the next version of my dreamplug series. Sorry to generate unnecessary searching on your part. Since it still hasn't made it in, I'll ask David Brown to feed his version into your queue. thx, Jason.
On Thu, 2012-08-30 at 20:14 +0100, Russell King - ARM Linux wrote: > On Thu, Aug 30, 2012 at 02:37:11PM -0400, Jason Cooper wrote: > > On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > > > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > > > > I've CC'd stable to see if they want to pick this up. > > > > > > That's not how stable works - and you'll probably receive a standard form > > > whinge from them about that. Please read up on the submission requirements > > > to the stable kernel trees. > > > > Ah, thanks. usually, I just add the Cc: line for fixes I send to > > arm-soc. Since this patch affects more than just kirkwood/marvell, I > > didn't feel it was appropriate to pull it in through my tree. > > Yes, you put the Cc: line in the commit, but you don't actually send it > to that address. [...] It's OK to cc the stable address when submitting to the relevant subsystem maintainer *as well as* including the cc: line in the commit message. It just can't be used as a substitute for the commit line. Ben.
On Fri, Aug 31, 2012 at 02:11:55PM -0700, Ben Hutchings wrote: > On Thu, 2012-08-30 at 20:14 +0100, Russell King - ARM Linux wrote: > > On Thu, Aug 30, 2012 at 02:37:11PM -0400, Jason Cooper wrote: > > > On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > > > > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > > > > > I've CC'd stable to see if they want to pick this up. > > > > > > > > That's not how stable works - and you'll probably receive a standard form > > > > whinge from them about that. Please read up on the submission requirements > > > > to the stable kernel trees. > > > > > > Ah, thanks. usually, I just add the Cc: line for fixes I send to > > > arm-soc. Since this patch affects more than just kirkwood/marvell, I > > > didn't feel it was appropriate to pull it in through my tree. > > > > Yes, you put the Cc: line in the commit, but you don't actually send it > > to that address. > [...] > > It's OK to cc the stable address when submitting to the relevant > subsystem maintainer *as well as* including the cc: line in the commit > message. It just can't be used as a substitute for the commit line. No it is not. It seems you also need to read Documentation/stable_kernel_rules.txt There are two ways to submit patches to the stable team: 1. send the patch to stable@vger.kernel.org _with_ the upstream commit ID _included_ in the message. You can't get that until it's been merged into the upstream tree, so you can't send it to stable@vger.kernel.org _until_ a maintainer has taken it and given you the ID. 2. Add the Cc: tag to the commit and let it be picked up automatically by the stable team when it hits mainline kernels. There are no other options. Definitely Cc'ing the stable address upon initial submission to the subsystem maintainer is _out_ of the question.
On Fri, 2012-08-31 at 23:32 +0100, Russell King - ARM Linux wrote: > On Fri, Aug 31, 2012 at 02:11:55PM -0700, Ben Hutchings wrote: > > On Thu, 2012-08-30 at 20:14 +0100, Russell King - ARM Linux wrote: > > > On Thu, Aug 30, 2012 at 02:37:11PM -0400, Jason Cooper wrote: > > > > On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > > > > > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > > > > > > I've CC'd stable to see if they want to pick this up. > > > > > > > > > > That's not how stable works - and you'll probably receive a standard form > > > > > whinge from them about that. Please read up on the submission requirements > > > > > to the stable kernel trees. > > > > > > > > Ah, thanks. usually, I just add the Cc: line for fixes I send to > > > > arm-soc. Since this patch affects more than just kirkwood/marvell, I > > > > didn't feel it was appropriate to pull it in through my tree. > > > > > > Yes, you put the Cc: line in the commit, but you don't actually send it > > > to that address. > > [...] > > > > It's OK to cc the stable address when submitting to the relevant > > subsystem maintainer *as well as* including the cc: line in the commit > > message. It just can't be used as a substitute for the commit line. > > No it is not. It seems you also need to read > Documentation/stable_kernel_rules.txt [...] None of which contradicts what I said above. There is no need for people to specifically filter out stable@vger.kernel.org from mail recipients. I never see any complaints from Greg or others when patches have it cc'd in both the commit message and the mail header; only when it is in the mail header *only*. Ben.
On Thu, Aug 30, 2012 at 07:14:47AM +0200, Andrew Lunn wrote: > Tools like kisskb are good at finding build regressions in the kernel > sources. However, regressions in the DT desscriptions are not found, > because generally these build systems don't build the DT binary blobs. > > Extend the ARM all target to build all enabled DTB files. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > --- > v2: * in the help test > Only invoke dtbs if CONFIGUSE_OF=y > > arch/arm/Makefile | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 30eae87..0457ef4 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -268,7 +268,12 @@ else > KBUILD_IMAGE := zImage > endif > > -all: $(KBUILD_IMAGE) > +# Build the DT binary blobs if we have OF configured > +ifeq ($(CONFIG_USE_OF),y) > +KBUILD_DTBS := dtbs > +endif > + > +all: $(KBUILD_IMAGE) $(KBUILD_DTBS) > > boot := arch/arm/boot > > @@ -306,7 +311,7 @@ define archhelp > echo ' uImage - U-Boot wrapped zImage' > echo ' bootpImage - Combined zImage and initial RAM disk' > echo ' (supply initrd image via make variable INITRD=<path>)' > - echo ' dtbs - Build device tree blobs for enabled boards' > + echo '* dtbs - Build device tree blobs for enabled boards' > echo ' install - Install uncompressed kernel' > echo ' zinstall - Install compressed kernel' > echo ' uinstall - Install U-Boot wrapped compressed kernel' > -- > 1.7.10.4 > Hi Folks Would anybody like to comment about the patch itself? Assuming the patch is acceptable, through which maintainers tree should it be submitted? Thanks Andrew
On Sat, Sep 01, 2012 at 03:20:16PM +0100, Ben Hutchings wrote: > On Fri, 2012-08-31 at 23:32 +0100, Russell King - ARM Linux wrote: > > On Fri, Aug 31, 2012 at 02:11:55PM -0700, Ben Hutchings wrote: > > > On Thu, 2012-08-30 at 20:14 +0100, Russell King - ARM Linux wrote: > > > > On Thu, Aug 30, 2012 at 02:37:11PM -0400, Jason Cooper wrote: > > > > > On Thu, Aug 30, 2012 at 06:23:04PM +0100, Russell King - ARM Linux wrote: > > > > > > On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote: > > > > > > > I've CC'd stable to see if they want to pick this up. > > > > > > > > > > > > That's not how stable works - and you'll probably receive a standard form > > > > > > whinge from them about that. Please read up on the submission requirements > > > > > > to the stable kernel trees. > > > > > > > > > > Ah, thanks. usually, I just add the Cc: line for fixes I send to > > > > > arm-soc. Since this patch affects more than just kirkwood/marvell, I > > > > > didn't feel it was appropriate to pull it in through my tree. > > > > > > > > Yes, you put the Cc: line in the commit, but you don't actually send it > > > > to that address. > > > [...] > > > > > > It's OK to cc the stable address when submitting to the relevant > > > subsystem maintainer *as well as* including the cc: line in the commit > > > message. It just can't be used as a substitute for the commit line. > > > > No it is not. It seems you also need to read > > Documentation/stable_kernel_rules.txt > [...] > > None of which contradicts what I said above. There is no need for I really can't believe you just said that. You have not read the document. Further discussion is pointless until you do, and I suggest everyone ignores your comments on this subject until you have read the document, because you are currently misleading people.
Hi Russell, Russell King - ARM Linux wrote: > On Sat, Sep 01, 2012 at 03:20:16PM +0100, Ben Hutchings wrote: >> On Fri, 2012-08-31 at 23:32 +0100, Russell King - ARM Linux wrote: >>> No it is not. It seems you also need to read >>> Documentation/stable_kernel_rules.txt >> [...] >> >> None of which contradicts what I said above. There is no need for > > I really can't believe you just said that. You have not read the document. Ben makes use of that document on a daily basis to maintain the 3.2.y tree, so I suspect he has read it. More importantly, as maintainer of a stable branch, I suspect he is familiar with the de facto rules. Is there some specific misleading wording in the document? Pointing it out, perhaps with a suggested replacement, could lead to the text being fixed, which would be a nice outcome that could make up for the pointlessly inflammatory discussion. Hoping that clarifies, Jonathan
On Sat, Sep 01, 2012 at 09:32:35AM -0700, Jonathan Nieder wrote: > Hi Russell, > > Russell King - ARM Linux wrote: > > On Sat, Sep 01, 2012 at 03:20:16PM +0100, Ben Hutchings wrote: > >> On Fri, 2012-08-31 at 23:32 +0100, Russell King - ARM Linux wrote: > > >>> No it is not. It seems you also need to read > >>> Documentation/stable_kernel_rules.txt > >> [...] > >> > >> None of which contradicts what I said above. There is no need for > > > > I really can't believe you just said that. You have not read the document. > > Ben makes use of that document on a daily basis to maintain the 3.2.y > tree, so I suspect he has read it. More importantly, as maintainer of > a stable branch, I suspect he is familiar with the de facto rules. > > Is there some specific misleading wording in the document? Pointing > it out, perhaps with a suggested replacement, could lead to the text > being fixed, which would be a nice outcome that could make up for the > pointlessly inflammatory discussion. I have pointed out the wording in my reply previous to the one above. The wording in the document is quite clear and unambiguous, and differs from Ben's statement. If Ben wishes to be more lenient than the document for the trees that he's looking after, then that is his perogative, but that doesn't mean that the stable rules applicable for general submission are any different from the documentation. Maybe Greg is not so lenient - so proposing new wording would be a foolish (and arrogant) act. It is for the stable team - and only the stable team as a whole - to decide whether the published rules are wrong and need modification. Until they do, the documented submission rules are The Rules and not some comments from anyone else (including individual stable maintainers.) I hope that the stable maintainers are discussing the issue amongst themselves now, and if necessary we'll see a patch to the documentation so that it reflects the proper position. Until that happens though, Ben's comments do not mean anything as far as general stable submission policy goes.
Hi Russell, Russell King wrote: > I have pointed out the wording in my reply previous to the one above. > The wording in the document is quite clear and unambiguous, and differs > from Ben's statement. Ah, ok. Meh. I guess we disagree about what the wording means. I think it's already clear. Here's what Greg wrote the last time he was asked: http://article.gmane.org/gmane.comp.version-control.git/178986 Ciao, Jonathan
On Sat, Sep 01, 2012 at 11:38:59AM -0700, Jonathan Nieder wrote: > Hi Russell, > > Russell King wrote: > > > I have pointed out the wording in my reply previous to the one above. > > The wording in the document is quite clear and unambiguous, and differs > > from Ben's statement. > > Ah, ok. > > Meh. I guess we disagree about what the wording means. I think it's > already clear. Okay, if you think it's clear, then you tell me where in this text, which is a direct quote from the stable_kernel_rules.txt document: | Procedure for submitting patches to the -stable tree: | | - Send the patch, after verifying that it follows the above rules, to | stable@vger.kernel.org. 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. | - To have the patch automatically included in the stable tree, add the tag | Cc: stable@vger.kernel.org | in the sign-off area. Once the patch is merged it will be applied to | the stable tree without anything else needing to be done by the author | or subsystem maintainer. it gives you permission to send a patch to the stable team email address _without_ the commit ID. Note carefully the sentence which starts "You must ...". "Must" is a very strong word, and doesn't give you any scope for "not doing the action". The rest of the points below that describe other items that may be required, but the above are the only two which refer to _how_ patches are _sent_ to the stable team. > Here's what Greg wrote the last time he was asked: > http://article.gmane.org/gmane.comp.version-control.git/178986 In which case, why did Greg reply with his standard form email telling Jason to read the stable_kernel_rules.txt document when Jason added the Cc to his email? It is as clear as mud now when stable@vger.kernel.org should be Cc'd and when it should not. On one hand Greg has said (in the URL you quote above) that he'd like discussion about stable patches to be copied to the stable team address. On the other hand, he replies with his standard form letter telling people not to do so when they do copy that address. I'm now totally confused. Clearly the document which Greg keeps pointing to is out of date. What _are_ the real situations when emails should be sent to the stable team? Can we have a definitive answer from Greg et.al - and can we have the documentation updated please ?
Russell King wrote: (out of order for convenience) > Okay, if you think it's clear, then you tell me where in this text, > which is a direct quote from the stable_kernel_rules.txt document: [...] > it gives you permission to send a patch to the stable team email address > _without_ the commit ID. Note carefully the sentence which starts "You Right here: [...] > | - To have the patch automatically included in the stable tree, add the tag > | Cc: stable@vger.kernel.org > | in the sign-off area. Once the patch is merged it will be applied to > | the stable tree without anything else needing to be done by the author > | or subsystem maintainer. If the tag "Cc: stable@vger.kernel.org" is in the sign-off area, you may cc the stable@ list or not. By justifying your change clearly and putting that tag in the sign-off area, you have done your job. Anything beyond that is completely up to you. That means: > In which case, why did Greg reply with his standard form email telling > Jason to read the stable_kernel_rules.txt document when Jason added the > Cc to his email? Because the "cc: stable" line was not in the sign-off area. Perhaps an extra sentence in stable_kernel_rules.txt would help. E.g., In this case, you may cc the stable@vger.kernel.org list when submitting your patch to keep the stable tree maintainers informed of the resulting discussion, but that is not required. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. Thanks, Jonathan
On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote: [...] > It is as clear as mud now when stable@vger.kernel.org should be Cc'd and > when it should not. [...] Perhaps what you're missing is that it's an open mailing list (as was stable@kernel.org), not an alias for 'the stable team'. As with any other kernel mailing list, you don't need to get explicit permission to send mail to it. So there is no 'should not'. Ben.
On Sun, Sep 02, 2012 at 02:54:27PM +0100, Ben Hutchings wrote: > On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote: > [...] > > It is as clear as mud now when stable@vger.kernel.org should be Cc'd and > > when it should not. > [...] > > Perhaps what you're missing is that it's an open mailing list (as was > stable@kernel.org), not an alias for 'the stable team'. As with any > other kernel mailing list, you don't need to get explicit permission to > send mail to it. So there is no 'should not'. Then please explain why people keep getting Greg's standard form "this is not how you submit patches for stable" when they CC a _discussion_ to the address. What you're saying does not tie up with what _actually_ happens in reality. Therefore I can only believe that you are wrong, even though you may be part of "the stable team". Please get your (collective) policy sorted out and properly documented, and you _all_ start behaving consistently. If you want stable@vger.kernel.org to be a list for discussion of stable patches, then fine - just don't then send standard form emails telling people they did something wrong when they _do_ try to use it for discussion. As I have pointed out many times in this thread, there is inconsistency between what you are saying, what Greg has said, what the documentation says, and the reaction that people get from Greg when they do send to that address. Something needs to change, and that isn't me - it's how the stable stuff operates. Because it's very confusing and inconsistent at the moment. Fix that problem and we can then all move along. Continue to ignore it and I'll continue my crusade against this blatent inconsistency. :)
On Sun, 2012-09-02 at 18:04 +0100, Russell King - ARM Linux wrote: > On Sun, Sep 02, 2012 at 02:54:27PM +0100, Ben Hutchings wrote: > > On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote: > > [...] > > > It is as clear as mud now when stable@vger.kernel.org should be Cc'd and > > > when it should not. > > [...] > > > > Perhaps what you're missing is that it's an open mailing list (as was > > stable@kernel.org), not an alias for 'the stable team'. As with any > > other kernel mailing list, you don't need to get explicit permission to > > send mail to it. So there is no 'should not'. > > Then please explain why people keep getting Greg's standard form "this > is not how you submit patches for stable" when they CC a _discussion_ > to the address. When someone sends a patch that they want to be applied in mainline and then later in stable updates, they must include the cc: line in the commit message. Actually cc'ing to the stable list is optional. When someone sends a preliminary version of a patch for discussion, and that might, after proper submission, be wanted in stable updates, that line is not necessary. The patch should however have '[RFC]' in the subject, so everyone understands that this is not a request for the patch to be applied. This should not result in a form response. I don't think this distinction between patch-to-be-applied and patch-to-be-discussed is anything peculiar to the stable list. [...] > As I have pointed out many times in this thread, there is inconsistency > between what you are saying, what Greg has said, what the documentation > says, and the reaction that people get from Greg when they do send to > that address. Something needs to change, and that isn't me - it's how > the stable stuff operates. Because it's very confusing and inconsistent > at the moment. > > Fix that problem and we can then all move along. Continue to ignore it > and I'll continue my crusade against this blatent inconsistency. :) I'm still failing to see any inconsistency. Ben.
On Sun, Sep 02, 2012 at 06:26:21PM +0100, Ben Hutchings wrote: > On Sun, 2012-09-02 at 18:04 +0100, Russell King - ARM Linux wrote: > > On Sun, Sep 02, 2012 at 02:54:27PM +0100, Ben Hutchings wrote: > > > On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote: > > > [...] > > > > It is as clear as mud now when stable@vger.kernel.org should be Cc'd and > > > > when it should not. > > > [...] > > > > > > Perhaps what you're missing is that it's an open mailing list (as was > > > stable@kernel.org), not an alias for 'the stable team'. As with any > > > other kernel mailing list, you don't need to get explicit permission to > > > send mail to it. So there is no 'should not'. > > > > Then please explain why people keep getting Greg's standard form "this > > is not how you submit patches for stable" when they CC a _discussion_ > > to the address. > > When someone sends a patch that they want to be applied in mainline and > then later in stable updates, they must include the cc: line in the > commit message. Actually cc'ing to the stable list is optional. > > When someone sends a preliminary version of a patch for discussion, and > that might, after proper submission, be wanted in stable updates, that > line is not necessary. The patch should however have '[RFC]' in the > subject, so everyone understands that this is not a request for the > patch to be applied. This should not result in a form response. You're still saying something different from the DOCUMENTED position and you're still refusing to accept that you are - even after I've quoted the _exact_ text which is _very_ _clear_. Please fix the documentation.
Hello, I try once to point out what I think is the misunderstanding in this thread. The stable team is never the first team/person who picks up a patch. So Jason saying: I've CC'd stable to see if they want to pick this up. got something wrong (either by not knowing how stable works or by being unclear). That's why Greg send out his form letter. Nevertheless you may still cc stable, but if you have the expectation that they pick it up without an other maintainer taking it first, you will be disappointed. If your mail's purpose is only to make the stable team aware of a patch that they might want to pick up later this is ok (and not covered by Documentation/stable_kernel_rules.txt). Best regards Uwe
On Sun, Sep 02, 2012 at 09:14:24PM +0200, Uwe Kleine-König wrote: > Hello, > > I try once to point out what I think is the misunderstanding in this > thread. > > The stable team is never the first team/person who picks up a patch. So > Jason saying: > > I've CC'd stable to see if they want to pick this up. > > got something wrong (either by not knowing how stable works or by being > unclear). That's why Greg send out his form letter. Exactly correct. If people wish to try to update stable_kernel_rules.txt to be a bit more descriptive, please do so. Personally, it seems detailed enough to me, and no one who gets this all wrong, seems to have even read the file in the first place, so odds are changing the file will not really help much. greg k-h > Nevertheless you may still cc stable, but if you have the expectation > that they pick it up without an other maintainer taking it first, you > will be disappointed. If your mail's purpose is only to make the stable > team aware of a patch that they might want to pick up later this is ok > (and not covered by Documentation/stable_kernel_rules.txt). > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | http://www.pengutronix.de/ | > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Sep 01, 2012 at 04:49:22PM +0200, Andrew Lunn wrote: > On Thu, Aug 30, 2012 at 07:14:47AM +0200, Andrew Lunn wrote: > > Tools like kisskb are good at finding build regressions in the kernel > > sources. However, regressions in the DT desscriptions are not found, > > because generally these build systems don't build the DT binary blobs. > > > > Extend the ARM all target to build all enabled DTB files. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > --- > > v2: * in the help test > > Only invoke dtbs if CONFIGUSE_OF=y > > > > arch/arm/Makefile | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > index 30eae87..0457ef4 100644 > > --- a/arch/arm/Makefile > > +++ b/arch/arm/Makefile > > @@ -268,7 +268,12 @@ else > > KBUILD_IMAGE := zImage > > endif > > > > -all: $(KBUILD_IMAGE) > > +# Build the DT binary blobs if we have OF configured > > +ifeq ($(CONFIG_USE_OF),y) > > +KBUILD_DTBS := dtbs > > +endif > > + > > +all: $(KBUILD_IMAGE) $(KBUILD_DTBS) > > > > boot := arch/arm/boot > > > > @@ -306,7 +311,7 @@ define archhelp > > echo ' uImage - U-Boot wrapped zImage' > > echo ' bootpImage - Combined zImage and initial RAM disk' > > echo ' (supply initrd image via make variable INITRD=<path>)' > > - echo ' dtbs - Build device tree blobs for enabled boards' > > + echo '* dtbs - Build device tree blobs for enabled boards' > > echo ' install - Install uncompressed kernel' > > echo ' zinstall - Install compressed kernel' > > echo ' uinstall - Install U-Boot wrapped compressed kernel' > > -- > > 1.7.10.4 > > > > Hi Folks > > Would anybody like to comment about the patch itself? > > Assuming the patch is acceptable, through which maintainers tree > should it be submitted? > > Thanks > Andrew My only concern here is that because of the missing make dependency between dtbs and dtc, this could cause unexpected build failures during parallel builds. However, so far as I can see this is not a problem unless explicit targets are put on the command line (which is already problematic with or without this patch). There is a separate patch under discussion to fix that, so your patch need not address it. This looks like a sensible fix for something which has been niggling at me, so Reviewed-by: Dave Martin <dave.martin@linaro.org> This is ARM core build system stuff, so I would expect that it should be submitted via Russell. Because this is related to DT, I suggest that you repost first, CC'ing devicetree-discuss@lists.ozlabs.org so those guys have a chance to comment (though the relevant people will generally be reading alkml anyway). They might have a view on whether there are better ways to write the patch ... but probably not. I'll leave it for the stable guys to judge whether this patch is appropriate for them. The patch itself is a feature addition, which would normally exclude it. But its inclusion might still be considered justified on grounds of improving build regression coverage of dtbs and dtc on stable. Cheers ---Dave
On Mon, Sep 03, 2012 at 01:21:34PM +0100, Dave Martin wrote: > I'll leave it for the stable guys to judge whether this patch is > appropriate for them. The patch itself is a feature addition, which > would normally exclude it. But its inclusion might still be considered > justified on grounds of improving build regression coverage of dtbs and > dtc on stable. Thank you for stating this more clearly than I originally did. This is exactly why I thought -stable would want it. thx, Jason.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 30eae87..0457ef4 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -268,7 +268,12 @@ else KBUILD_IMAGE := zImage endif -all: $(KBUILD_IMAGE) +# Build the DT binary blobs if we have OF configured +ifeq ($(CONFIG_USE_OF),y) +KBUILD_DTBS := dtbs +endif + +all: $(KBUILD_IMAGE) $(KBUILD_DTBS) boot := arch/arm/boot @@ -306,7 +311,7 @@ define archhelp echo ' uImage - U-Boot wrapped zImage' echo ' bootpImage - Combined zImage and initial RAM disk' echo ' (supply initrd image via make variable INITRD=<path>)' - echo ' dtbs - Build device tree blobs for enabled boards' + echo '* dtbs - Build device tree blobs for enabled boards' echo ' install - Install uncompressed kernel' echo ' zinstall - Install compressed kernel' echo ' uinstall - Install U-Boot wrapped compressed kernel'
Tools like kisskb are good at finding build regressions in the kernel sources. However, regressions in the DT desscriptions are not found, because generally these build systems don't build the DT binary blobs. Extend the ARM all target to build all enabled DTB files. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- v2: * in the help test Only invoke dtbs if CONFIGUSE_OF=y arch/arm/Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)