ARM: Build dtb files in all target
PATCH v2 1/1 ARM: Build dtb files in all target
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.
---
v2: * in the help test
Only invoke dtbs if CONFIGUSE_OF=y
arch/arm/Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
arch/arm/Makefile +7 -2
@@ -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'
Signature · 1 line
1.7.10.4
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 7 lines · Andrew Lunn
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 <[email protected]>
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.
Quoted 42 lines
---
v2: * in the help test
Only invoke dtbs if CONFIGUSE_OF=yarch/arm/Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)arch/arm/Makefile +7
-2@@ -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'Signature · 7 lines
1.7.10.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 5 lines · Jason Cooper
Quoted 4 lines · Andrew Lunn
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.
Quoted 7 lines
Quoted 3 lines
Extend the ARM all target to build all enabled DTB files.
Signed-off-by Andrew Lunn <[email protected]>Acked-by Jason Cooper <[email protected]>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.
Quoted 4 lines
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.
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 6 lines · Russell King - ARM Linux
Quoted 1 line · Jason Cooper
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.
Quoted 14 lines
Quoted 3 lines
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: Fixioremap()of address zero
Quoted 2 lines
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.
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 11 lines · Jason Cooper
Quoted 6 lines · Russell King - ARM Linux
Quoted 1 line · Jason Cooper
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.
Quoted 6 lines
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...
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 3 lines · Russell King - ARM Linux
Quoted 2 lines · Jason Cooper
Quoted 1 line · Russell King - ARM Linux
On Thu, Aug 30, 2012 at 12:52:24PM -0400, Jason Cooper wrote:
...
Quoted 11 lines
Quoted 6 lines
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.
PATCH v2 1/1 ARM: Build dtb files in all target
In reply to Russell King - ARM LinuxQuoted 9 lines · Russell King - ARM Linux
Quoted 8 lines · Jason Cooper
Quoted 6 lines · Russell King - ARM Linux
Quoted 1 line · Jason Cooper
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.
Quoted 6 lines
Quoted 3 lines
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.
Signature · 10 lines
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120831/65be9d18/attachment.sig>PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 14 lines · Ben Hutchings
Quoted 13 lines · Russell King - ARM Linux
Quoted 11 lines · Jason Cooper
Quoted 6 lines · Russell King - ARM Linux
Quoted 1 line · Jason Cooper
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.
Quoted 7 lines
Quoted 2 lines
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 readDocumentation/stable_kernel_rules.txt
There are two ways to submit patches to the stable team:
1. send the patch to stable at 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 at 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.
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 17 lines · Russell King - ARM Linux
Quoted 16 lines · Ben Hutchings
Quoted 15 lines · Russell King - ARM Linux
Quoted 11 lines · Jason Cooper
Quoted 6 lines · Russell King - ARM Linux
Quoted 1 line · Jason Cooper
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.
Quoted 8 lines
Quoted 5 lines
[...]
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 at 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.
Signature · 10 lines
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120901/484b5bae/attachment.sig>PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 24 lines · Ben Hutchings
Quoted 23 lines · Russell King - ARM Linux
Quoted 21 lines · Ben Hutchings
Quoted 9 lines · Russell King - ARM Linux
Quoted 8 lines · Jason Cooper
Quoted 6 lines · Russell King - ARM Linux
Quoted 1 line · Jason Cooper
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
PATCH v2 1/1 ARM: Build dtb files in all target
Hi Russell,
Quoted 10 lines · Russell King - ARM Linux
Quoted 7 lines · Ben Hutchings
Quoted 2 lines · Russell King - ARM Linux
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
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 14 lines · Jonathan Nieder
Hi Russell,
Quoted 10 lines · Russell King - ARM Linux
Quoted 7 lines · Ben Hutchings
Quoted 2 lines · Russell King - ARM Linux
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.
Quoted 8 lines
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.
PATCH v2 1/1 ARM: Build dtb files in all target
Hi Russell,
Quoted 3 lines · Russell King
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
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 4 lines · Jonathan Nieder
Hi Russell,
Russell King wrote:
Quoted 8 lines
Quoted 3 lines
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 at 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 at 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.
Quoted 2 lines
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 at 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 ?
When to cc [email protected] (Re: [PATCH v2] ARM: Build dtb files in all target)
Russell King wrote:
(out of order for convenience)
Quoted 2 lines
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:
[...]
Quoted 2 lines
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:
[...]
Quoted 5 lines
| - To have the patch automatically included in the stable tree, add the tag | Cc: stable at 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 at 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:
Quoted 3 lines
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 at 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
PATCH v2 1/1 ARM: Build dtb files in all target
In reply to Russell King - ARM LinuxOn Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote:
[...]
Quoted 2 lines
It is as clear as mud now when stable at 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 at 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.
Signature · 10 lines
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120902/4e3526a3/attachment.sig>PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 10 lines · Ben Hutchings
On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote:
[...]Quoted 2 lines
It is as clear as mud now when stable at 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 at 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 at 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. :)
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Ben Hutchings
On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote:
[...]Quoted 2 lines
It is as clear as mud now when stable at vger.kernel.org should be Cc'd and when it should not.
[...]
Quoted 8 lines
Quoted 4 lines
Perhaps what you're missing is that it's an open mailing list (as was stable at 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.
[...]
Quoted 9 lines
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.
Signature · 10 lines
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120902/6d4ce281/attachment.sig>PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 21 lines · Ben Hutchings
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Ben Hutchings
On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote:
[...]Quoted 2 lines
It is as clear as mud now when stable at vger.kernel.org should be Cc'd and when it should not.
[...]
Quoted 8 lines
Quoted 4 lines
Perhaps what you're missing is that it's an open mailing list (as was stable at 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.
Quoted 5 lines
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.
PATCH v2 1/1 ARM: Build dtb files in all target
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
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 5 lines · Uwe Kleine-K?nig
Hello,
I try once to point out what I think is the misunderstanding in this thread.
Quoted 7 lines
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
Quoted 16 lines
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
UweSignature · 6 lines
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 at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v2 1/1 ARM: Build dtb files in all target
In reply to Jason CooperQuoted 7 lines · Jason Cooper
Quoted 6 lines · Andrew Lunn
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.
Quoted 8 lines
Quoted 1 line
Signed-off-by Andrew Lunn <[email protected]>Acked-by Jason Cooper <[email protected]>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>
PATCH v2 1/1 ARM: Build dtb files in all target
In reply to Andrew LunnQuoted 44 lines · Andrew Lunn
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 <[email protected]>---
v2: * in the help test
Only invoke dtbs if CONFIGUSE_OF=yarch/arm/Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)arch/arm/Makefile +7
-2@@ -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'Signature · 1 line
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
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 48 lines · Andrew Lunn
Quoted 44 lines · Andrew Lunn
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 <[email protected]>---
v2: * in the help test
Only invoke dtbs if CONFIGUSE_OF=yarch/arm/Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)arch/arm/Makefile +7
-2@@ -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'Signature · 1 line
1.7.10.4Hi Folks
Quoted 7 lines
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
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 at 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
PATCH v2 1/1 ARM: Build dtb files in all target
Quoted 5 lines · Dave Martin
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.