[PATCH v2] ARM: Build dtb files in all target

[PATCH v2] ARM: Build dtb files in all target

[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 <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

[PATCH v2] ARM: Build dtb files in all target

[Jason Cooper]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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.

[PATCH v2] ARM: Build dtb files in all target

[Jason Cooper]

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.

[PATCH v2] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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...

[PATCH v2] ARM: Build dtb files in all target

[Jason Cooper]

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.

[PATCH v2] ARM: Build dtb files in all target

[Ben Hutchings]

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.

-- 
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] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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 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] ARM: Build dtb files in all target

[Ben Hutchings]

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 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.

-- 
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] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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.

[PATCH v2] ARM: Build dtb files in all target

[Jonathan Nieder]

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

[PATCH v2] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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.

[PATCH v2] ARM: Build dtb files in all target

[Jonathan Nieder]

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

[PATCH v2] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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 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.

> 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 stable@vger.kernel.org (Re: [PATCH v2] ARM: Build dtb files in all target)

[Jonathan Nieder]

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 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:

> 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] ARM: Build dtb files in all target

[Ben Hutchings]

On Sat, 2012-09-01 at 21:11 +0100, Russell King - ARM Linux wrote:
[...]
> 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.

-- 
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] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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 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] ARM: Build dtb files in all target

[Ben Hutchings]

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 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.

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.

-- 
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] ARM: Build dtb files in all target

[Russell King - ARM Linux]

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 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.
> 
> 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.

[PATCH v2] ARM: Build dtb files in all target

[Uwe Kleine-König]

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

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH v2] ARM: Build dtb files in all target

[Greg KH]

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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: Build dtb files in all target

[Greg KH]

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>

[PATCH v2] ARM: Build dtb files in all target

[Andrew Lunn]

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

[PATCH v2] ARM: Build dtb files in all target

[Dave Martin]

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 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] ARM: Build dtb files in all target

[Jason Cooper]

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.