* [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 14:14 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 14:14 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
>
> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
> > > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> > > > >>> Please send it to RMK's patch system.
> > > > >>
> > > > >> Done (I hope so ;-)
> > > > >
> > > > > Failed. Retrying.
> > > >
> > > > Yiha ;-)
> > > >
> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
> > >
> > > This also fixes the spamming I started seeing with next-20171009:
> > >
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> >
> > It's all nice and good that people are testing this patch, but I can't
> > apply it to -rc1, nor my "misc" branch. It appears that this is due
> > to patches going through other trees.
> >
> > Sorry, I can't take this patch.
>
> It should go into your devel-testing branch as this must be applied on
> top of my xip_zdata branch that you merged there.
Thanks, it would've been good to have known that ahead of time.
It's why the patch system has the KernelVersion: tag:
?6.?Kernel version.
On a separate line, add a tag "KernelVersion: " followed by the kernel
version that the patch was generated against. This should be formatted
as "KernelVersion: 2.6.0-rmk1"
This is because that information is relevant for knowing where it should
be applied, and to which branch. Having it be something else means I
have to guess, and that can result in the patch being discarded in this
manner if I don't find where it's supposed to be applied.
Yes, I know it's a pain to have to supply this information, but giving
accurate information there makes things a lot easier and quicker when
applying patches, rather than playing a game of "guess where it needs
to be applied, nope, doesn't apply there, try somewhere else."
Various people in the kernel community have different solutions to this.
For example, on netdev, it is preferred to state whether you want your
patch to be applied to "net" or "net-next" by adding that into the
"[PATCH ...]" tag in the subject line. It's really about streamlining
the patch submission and application process.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 14:14 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 14:14 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
>
> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
> > > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> > > > >>> Please send it to RMK's patch system.
> > > > >>
> > > > >> Done (I hope so ;-)
> > > > >
> > > > > Failed. Retrying.
> > > >
> > > > Yiha ;-)
> > > >
> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
> > >
> > > This also fixes the spamming I started seeing with next-20171009:
> > >
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> >
> > It's all nice and good that people are testing this patch, but I can't
> > apply it to -rc1, nor my "misc" branch. It appears that this is due
> > to patches going through other trees.
> >
> > Sorry, I can't take this patch.
>
> It should go into your devel-testing branch as this must be applied on
> top of my xip_zdata branch that you merged there.
Thanks, it would've been good to have known that ahead of time.
It's why the patch system has the KernelVersion: tag:
�6.�Kernel version.
On a separate line, add a tag "KernelVersion: " followed by the kernel
version that the patch was generated against. This should be formatted
as "KernelVersion: 2.6.0-rmk1"
This is because that information is relevant for knowing where it should
be applied, and to which branch. Having it be something else means I
have to guess, and that can result in the patch being discarded in this
manner if I don't find where it's supposed to be applied.
Yes, I know it's a pain to have to supply this information, but giving
accurate information there makes things a lot easier and quicker when
applying patches, rather than playing a game of "guess where it needs
to be applied, nope, doesn't apply there, try somewhere else."
Various people in the kernel community have different solutions to this.
For example, on netdev, it is preferred to state whether you want your
patch to be applied to "net" or "net-next" by adding that into the
"[PATCH ...]" tag in the subject line. It's really about streamlining
the patch submission and application process.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
2017-10-14 14:14 ` Russell King - ARM Linux
(?)
@ 2017-10-14 14:17 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 14:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > It should go into your devel-testing branch as this must be applied on
> > top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
> 6. Kernel version.
> On a separate line, add a tag "KernelVersion: " followed by the kernel
> version that the patch was generated against. This should be formatted
> as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch. Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.
>
> Yes, I know it's a pain to have to supply this information, but giving
> accurate information there makes things a lot easier and quicker when
> applying patches, rather than playing a game of "guess where it needs
> to be applied, nope, doesn't apply there, try somewhere else."
>
> Various people in the kernel community have different solutions to this.
> For example, on netdev, it is preferred to state whether you want your
> patch to be applied to "net" or "net-next" by adding that into the
> "[PATCH ...]" tag in the subject line. It's really about streamlining
> the patch submission and application process.
The tag can take a plain kernel version and a kernel version suffixed
with a shortened git hash (please avoid the full hash, it doesn't
display well with the web presentation, and will probably be truncated
when it's inserted into the database.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 14:17 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 14:17 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > It should go into your devel-testing branch as this must be applied on
> > top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
> ?6.?Kernel version.
> On a separate line, add a tag "KernelVersion: " followed by the kernel
> version that the patch was generated against. This should be formatted
> as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch. Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.
>
> Yes, I know it's a pain to have to supply this information, but giving
> accurate information there makes things a lot easier and quicker when
> applying patches, rather than playing a game of "guess where it needs
> to be applied, nope, doesn't apply there, try somewhere else."
>
> Various people in the kernel community have different solutions to this.
> For example, on netdev, it is preferred to state whether you want your
> patch to be applied to "net" or "net-next" by adding that into the
> "[PATCH ...]" tag in the subject line. It's really about streamlining
> the patch submission and application process.
The tag can take a plain kernel version and a kernel version suffixed
with a shortened git hash (please avoid the full hash, it doesn't
display well with the web presentation, and will probably be truncated
when it's inserted into the database.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 14:17 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 14:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > It should go into your devel-testing branch as this must be applied on
> > top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
> �6.�Kernel version.
> On a separate line, add a tag "KernelVersion: " followed by the kernel
> version that the patch was generated against. This should be formatted
> as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch. Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.
>
> Yes, I know it's a pain to have to supply this information, but giving
> accurate information there makes things a lot easier and quicker when
> applying patches, rather than playing a game of "guess where it needs
> to be applied, nope, doesn't apply there, try somewhere else."
>
> Various people in the kernel community have different solutions to this.
> For example, on netdev, it is preferred to state whether you want your
> patch to be applied to "net" or "net-next" by adding that into the
> "[PATCH ...]" tag in the subject line. It's really about streamlining
> the patch submission and application process.
The tag can take a plain kernel version and a kernel version suffixed
with a shortened git hash (please avoid the full hash, it doesn't
display well with the web presentation, and will probably be truncated
when it's inserted into the database.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
2017-10-14 14:17 ` Russell King - ARM Linux
(?)
@ 2017-10-14 15:49 ` Nicolas Pitre
-1 siblings, 0 replies; 34+ messages in thread
From: Nicolas Pitre @ 2017-10-14 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > It should go into your devel-testing branch as this must be applied on
> > > top of my xip_zdata branch that you merged there.
> >
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> > 6. Kernel version.
> > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > version that the patch was generated against. This should be formatted
> > as "KernelVersion: 2.6.0-rmk1"
> >
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch. Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
> >
> > Yes, I know it's a pain to have to supply this information, but giving
> > accurate information there makes things a lot easier and quicker when
> > applying patches, rather than playing a game of "guess where it needs
> > to be applied, nope, doesn't apply there, try somewhere else."
> >
> > Various people in the kernel community have different solutions to this.
> > For example, on netdev, it is preferred to state whether you want your
> > patch to be applied to "net" or "net-next" by adding that into the
> > "[PATCH ...]" tag in the subject line. It's really about streamlining
> > the patch submission and application process.
>
> The tag can take a plain kernel version and a kernel version suffixed
> with a shortened git hash (please avoid the full hash, it doesn't
> display well with the web presentation, and will probably be truncated
> when it's inserted into the database.)
Probably what you want is the output of 'git describe'.
Nicolas
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 15:49 ` Nicolas Pitre
0 siblings, 0 replies; 34+ messages in thread
From: Nicolas Pitre @ 2017-10-14 15:49 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > It should go into your devel-testing branch as this must be applied on
> > > top of my xip_zdata branch that you merged there.
> >
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> > ?6.?Kernel version.
> > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > version that the patch was generated against. This should be formatted
> > as "KernelVersion: 2.6.0-rmk1"
> >
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch. Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
> >
> > Yes, I know it's a pain to have to supply this information, but giving
> > accurate information there makes things a lot easier and quicker when
> > applying patches, rather than playing a game of "guess where it needs
> > to be applied, nope, doesn't apply there, try somewhere else."
> >
> > Various people in the kernel community have different solutions to this.
> > For example, on netdev, it is preferred to state whether you want your
> > patch to be applied to "net" or "net-next" by adding that into the
> > "[PATCH ...]" tag in the subject line. It's really about streamlining
> > the patch submission and application process.
>
> The tag can take a plain kernel version and a kernel version suffixed
> with a shortened git hash (please avoid the full hash, it doesn't
> display well with the web presentation, and will probably be truncated
> when it's inserted into the database.)
Probably what you want is the output of 'git describe'.
Nicolas
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 15:49 ` Nicolas Pitre
0 siblings, 0 replies; 34+ messages in thread
From: Nicolas Pitre @ 2017-10-14 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > It should go into your devel-testing branch as this must be applied on
> > > top of my xip_zdata branch that you merged there.
> >
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> > �6.�Kernel version.
> > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > version that the patch was generated against. This should be formatted
> > as "KernelVersion: 2.6.0-rmk1"
> >
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch. Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
> >
> > Yes, I know it's a pain to have to supply this information, but giving
> > accurate information there makes things a lot easier and quicker when
> > applying patches, rather than playing a game of "guess where it needs
> > to be applied, nope, doesn't apply there, try somewhere else."
> >
> > Various people in the kernel community have different solutions to this.
> > For example, on netdev, it is preferred to state whether you want your
> > patch to be applied to "net" or "net-next" by adding that into the
> > "[PATCH ...]" tag in the subject line. It's really about streamlining
> > the patch submission and application process.
>
> The tag can take a plain kernel version and a kernel version suffixed
> with a shortened git hash (please avoid the full hash, it doesn't
> display well with the web presentation, and will probably be truncated
> when it's inserted into the database.)
Probably what you want is the output of 'git describe'.
Nicolas
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
2017-10-14 15:49 ` Nicolas Pitre
(?)
@ 2017-10-14 18:20 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 18:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
On Sat, Oct 14, 2017 at 11:49:25AM -0400, Nicolas Pitre wrote:
> On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> > On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > > It should go into your devel-testing branch as this must be applied on
> > > > top of my xip_zdata branch that you merged there.
> > >
> > > Thanks, it would've been good to have known that ahead of time.
> > >
> > > It's why the patch system has the KernelVersion: tag:
> > >
> > > 6. Kernel version.
> > > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > > version that the patch was generated against. This should be formatted
> > > as "KernelVersion: 2.6.0-rmk1"
> > >
> > > This is because that information is relevant for knowing where it should
> > > be applied, and to which branch. Having it be something else means I
> > > have to guess, and that can result in the patch being discarded in this
> > > manner if I don't find where it's supposed to be applied.
> > >
> > > Yes, I know it's a pain to have to supply this information, but giving
> > > accurate information there makes things a lot easier and quicker when
> > > applying patches, rather than playing a game of "guess where it needs
> > > to be applied, nope, doesn't apply there, try somewhere else."
> > >
> > > Various people in the kernel community have different solutions to this.
> > > For example, on netdev, it is preferred to state whether you want your
> > > patch to be applied to "net" or "net-next" by adding that into the
> > > "[PATCH ...]" tag in the subject line. It's really about streamlining
> > > the patch submission and application process.
> >
> > The tag can take a plain kernel version and a kernel version suffixed
> > with a shortened git hash (please avoid the full hash, it doesn't
> > display well with the web presentation, and will probably be truncated
> > when it's inserted into the database.)
>
> Probably what you want is the output of 'git describe'.
Yes and no. It certainly contains the information, but I think it's
too long. 4.14-rc1-g123456789abc is sufficient - no need for the
leading 'v' and no need for a count of the number of commits between
the tag and the shortened sha hash.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 18:20 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 18:20 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Oct 14, 2017 at 11:49:25AM -0400, Nicolas Pitre wrote:
> On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> > On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > > It should go into your devel-testing branch as this must be applied on
> > > > top of my xip_zdata branch that you merged there.
> > >
> > > Thanks, it would've been good to have known that ahead of time.
> > >
> > > It's why the patch system has the KernelVersion: tag:
> > >
> > > ?6.?Kernel version.
> > > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > > version that the patch was generated against. This should be formatted
> > > as "KernelVersion: 2.6.0-rmk1"
> > >
> > > This is because that information is relevant for knowing where it should
> > > be applied, and to which branch. Having it be something else means I
> > > have to guess, and that can result in the patch being discarded in this
> > > manner if I don't find where it's supposed to be applied.
> > >
> > > Yes, I know it's a pain to have to supply this information, but giving
> > > accurate information there makes things a lot easier and quicker when
> > > applying patches, rather than playing a game of "guess where it needs
> > > to be applied, nope, doesn't apply there, try somewhere else."
> > >
> > > Various people in the kernel community have different solutions to this.
> > > For example, on netdev, it is preferred to state whether you want your
> > > patch to be applied to "net" or "net-next" by adding that into the
> > > "[PATCH ...]" tag in the subject line. It's really about streamlining
> > > the patch submission and application process.
> >
> > The tag can take a plain kernel version and a kernel version suffixed
> > with a shortened git hash (please avoid the full hash, it doesn't
> > display well with the web presentation, and will probably be truncated
> > when it's inserted into the database.)
>
> Probably what you want is the output of 'git describe'.
Yes and no. It certainly contains the information, but I think it's
too long. 4.14-rc1-g123456789abc is sufficient - no need for the
leading 'v' and no need for a count of the number of commits between
the tag and the shortened sha hash.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-14 18:20 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-14 18:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel, Tony Lindgren,
linux-kernel@vger.kernel.org, Linux-Renesas, Chris Brandt,
Geert Uytterhoeven, linux-omap,
linux-arm-kernel@lists.infradead.org
On Sat, Oct 14, 2017 at 11:49:25AM -0400, Nicolas Pitre wrote:
> On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> > On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > > It should go into your devel-testing branch as this must be applied on
> > > > top of my xip_zdata branch that you merged there.
> > >
> > > Thanks, it would've been good to have known that ahead of time.
> > >
> > > It's why the patch system has the KernelVersion: tag:
> > >
> > > �6.�Kernel version.
> > > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > > version that the patch was generated against. This should be formatted
> > > as "KernelVersion: 2.6.0-rmk1"
> > >
> > > This is because that information is relevant for knowing where it should
> > > be applied, and to which branch. Having it be something else means I
> > > have to guess, and that can result in the patch being discarded in this
> > > manner if I don't find where it's supposed to be applied.
> > >
> > > Yes, I know it's a pain to have to supply this information, but giving
> > > accurate information there makes things a lot easier and quicker when
> > > applying patches, rather than playing a game of "guess where it needs
> > > to be applied, nope, doesn't apply there, try somewhere else."
> > >
> > > Various people in the kernel community have different solutions to this.
> > > For example, on netdev, it is preferred to state whether you want your
> > > patch to be applied to "net" or "net-next" by adding that into the
> > > "[PATCH ...]" tag in the subject line. It's really about streamlining
> > > the patch submission and application process.
> >
> > The tag can take a plain kernel version and a kernel version suffixed
> > with a shortened git hash (please avoid the full hash, it doesn't
> > display well with the web presentation, and will probably be truncated
> > when it's inserted into the database.)
>
> Probably what you want is the output of 'git describe'.
Yes and no. It certainly contains the information, but I think it's
too long. 4.14-rc1-g123456789abc is sufficient - no need for the
leading 'v' and no need for a count of the number of commits between
the tag and the shortened sha hash.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
2017-10-14 14:14 ` Russell King - ARM Linux
@ 2017-10-15 8:04 ` Geert Uytterhoeven
-1 siblings, 0 replies; 34+ messages in thread
From: Geert Uytterhoeven @ 2017-10-15 8:04 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel,
Tony Lindgren, linux-kernel@vger.kernel.org, Linux-Renesas,
Chris Brandt, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
>> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
>>
>> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
>> > > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
>> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> > > > >>> Please send it to RMK's patch system.
>> > > > >>
>> > > > >> Done (I hope so ;-)
>> > > > >
>> > > > > Failed. Retrying.
>> > > >
>> > > > Yiha ;-)
>> > > >
>> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
>> > >
>> > > This also fixes the spamming I started seeing with next-20171009:
>> > >
>> > > Tested-by: Tony Lindgren <tony@atomide.com>
>> >
>> > It's all nice and good that people are testing this patch, but I can't
>> > apply it to -rc1, nor my "misc" branch. It appears that this is due
>> > to patches going through other trees.
>> >
>> > Sorry, I can't take this patch.
>>
>> It should go into your devel-testing branch as this must be applied on
>> top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
> 6. Kernel version.
> On a separate line, add a tag "KernelVersion: " followed by the kernel
> version that the patch was generated against. This should be formatted
> as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch. Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.
That's why we have the standard Fixes tag, which was included
Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
It's trivial for the repo maintainer to know which branch the fix to apply to,
given the Fixes tag.
It's non-trivial to know the branch for the patch submitter, who is forced to
use a non-standard patch submission system.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-15 8:04 ` Geert Uytterhoeven
0 siblings, 0 replies; 34+ messages in thread
From: Geert Uytterhoeven @ 2017-10-15 8:04 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
>> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
>>
>> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
>> > > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
>> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> > > > >>> Please send it to RMK's patch system.
>> > > > >>
>> > > > >> Done (I hope so ;-)
>> > > > >
>> > > > > Failed. Retrying.
>> > > >
>> > > > Yiha ;-)
>> > > >
>> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
>> > >
>> > > This also fixes the spamming I started seeing with next-20171009:
>> > >
>> > > Tested-by: Tony Lindgren <tony@atomide.com>
>> >
>> > It's all nice and good that people are testing this patch, but I can't
>> > apply it to -rc1, nor my "misc" branch. It appears that this is due
>> > to patches going through other trees.
>> >
>> > Sorry, I can't take this patch.
>>
>> It should go into your devel-testing branch as this must be applied on
>> top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
> 6. Kernel version.
> On a separate line, add a tag "KernelVersion: " followed by the kernel
> version that the patch was generated against. This should be formatted
> as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch. Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.
That's why we have the standard Fixes tag, which was included
Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
It's trivial for the repo maintainer to know which branch the fix to apply to,
given the Fixes tag.
It's non-trivial to know the branch for the patch submitter, who is forced to
use a non-standard patch submission system.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
2017-10-15 8:04 ` Geert Uytterhoeven
@ 2017-10-16 12:29 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-16 12:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Nicolas Pitre, Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel,
Tony Lindgren, linux-kernel@vger.kernel.org, Linux-Renesas,
Chris Brandt, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
On Sun, Oct 15, 2017 at 10:04:16AM +0200, Geert Uytterhoeven wrote:
> On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> > 6. Kernel version.
> > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > version that the patch was generated against. This should be formatted
> > as "KernelVersion: 2.6.0-rmk1"
> >
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch. Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
>
> That's why we have the standard Fixes tag, which was included
> Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
Wrong. You're confusing two different things.
The fixes tag identifies the commit to which the FIX applies. That's
not what the kernelversion tag described above is for. That's to
describe where the patch was GENERATED, so that it's easier to know
where it should be applied.
> It's trivial for the repo maintainer to know which branch the fix to
> apply to, given the Fixes tag.
> It's non-trivial to know the branch for the patch submitter, who is
> forced to use a non-standard patch submission system.
So what you're telling me is that you're unable to describe what commit
or the kernel version that the patch was GENERATED against.
I /really/ don't buy such an argument one bit. If you don't have that
information, by definition you can't generate a git patch.
If it was trivial, then don't you think the patch would've been applied
without all this crap? The proof is here in this thread, it's not as
trivial as you think it is.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()
@ 2017-10-16 12:29 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-10-16 12:29 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Oct 15, 2017 at 10:04:16AM +0200, Geert Uytterhoeven wrote:
> On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> > 6. Kernel version.
> > On a separate line, add a tag "KernelVersion: " followed by the kernel
> > version that the patch was generated against. This should be formatted
> > as "KernelVersion: 2.6.0-rmk1"
> >
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch. Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
>
> That's why we have the standard Fixes tag, which was included
> Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
Wrong. You're confusing two different things.
The fixes tag identifies the commit to which the FIX applies. That's
not what the kernelversion tag described above is for. That's to
describe where the patch was GENERATED, so that it's easier to know
where it should be applied.
> It's trivial for the repo maintainer to know which branch the fix to
> apply to, given the Fixes tag.
> It's non-trivial to know the branch for the patch submitter, who is
> forced to use a non-standard patch submission system.
So what you're telling me is that you're unable to describe what commit
or the kernel version that the patch was GENERATED against.
I /really/ don't buy such an argument one bit. If you don't have that
information, by definition you can't generate a git patch.
If it was trivial, then don't you think the patch would've been applied
without all this crap? The proof is here in this thread, it's not as
trivial as you think it is.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread