All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org,
	lkml <linux-kernel@vger.kernel.org>,
	arm@kernel.org
Subject: Re: [PULL REQ] IXP4xx changes for Linux 3.7
Date: Sun, 14 Oct 2012 20:02:55 +0000	[thread overview]
Message-ID: <201210142002.55841.arnd@arndb.de> (raw)
In-Reply-To: <m3bog6m5iz.fsf@intrepid.localdomain>

On Saturday 13 October 2012, Krzysztof Halasa wrote:
> Linus,
> 
> please pull my ARM IXP4xx changes for 3.7:
> 
> The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:
> 
> "Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security"
> (2012-10-13 11:29:00 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next
> 
> for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d:
>   IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200)
> 
> Build-tested for now. This is based on your current tree tip because it
> depends on commits following 3.6 release.

Hi Krzysztof,

as mentioned before, all arch/arm/mach-* patches should go through the
arm-soc tree or get an Ack from the arm-soc maintainers. The same thing
is true for the char-misc and the crypto trees.

Also, never rebase your tree immediately before sending a pull request.
The preferred way is to have everything based on the -rc release that
is the latest one at the time when you do your testing. If you rebase
later, you essentially have to test everything again.

Finally when sending bug fixes, please annotate any patches with
'Cc: stable@vger.kernel.org' if they address bugs that are already
present in older kernels, so that the stable and longterm maintainers
can easily backport the fixes.

Almost all of the platform patches in your tree seem to be bug fixes,
so they are still good for inclusion in v3.7 if you submit them to
arm-soc soon, but please make sure you separate bug fixes from other
changes so we can group them appropriately when forwarding them to
Linus.

Thanks,

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PULL REQ] IXP4xx changes for Linux 3.7
Date: Sun, 14 Oct 2012 20:02:55 +0000	[thread overview]
Message-ID: <201210142002.55841.arnd@arndb.de> (raw)
In-Reply-To: <m3bog6m5iz.fsf@intrepid.localdomain>

On Saturday 13 October 2012, Krzysztof Halasa wrote:
> Linus,
> 
> please pull my ARM IXP4xx changes for 3.7:
> 
> The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:
> 
> "Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security"
> (2012-10-13 11:29:00 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next
> 
> for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d:
>   IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200)
> 
> Build-tested for now. This is based on your current tree tip because it
> depends on commits following 3.6 release.

Hi Krzysztof,

as mentioned before, all arch/arm/mach-* patches should go through the
arm-soc tree or get an Ack from the arm-soc maintainers. The same thing
is true for the char-misc and the crypto trees.

Also, never rebase your tree immediately before sending a pull request.
The preferred way is to have everything based on the -rc release that
is the latest one at the time when you do your testing. If you rebase
later, you essentially have to test everything again.

Finally when sending bug fixes, please annotate any patches with
'Cc: stable at vger.kernel.org' if they address bugs that are already
present in older kernels, so that the stable and longterm maintainers
can easily backport the fixes.

Almost all of the platform patches in your tree seem to be bug fixes,
so they are still good for inclusion in v3.7 if you submit them to
arm-soc soon, but please make sure you separate bug fixes from other
changes so we can group them appropriately when forwarding them to
Linus.

Thanks,

	Arnd

  reply	other threads:[~2012-10-14 20:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-13 21:22 [PULL REQ] IXP4xx changes for Linux 3.7 Krzysztof Halasa
2012-10-13 21:22 ` Krzysztof Halasa
2012-10-14 20:02 ` Arnd Bergmann [this message]
2012-10-14 20:02   ` Arnd Bergmann
2012-10-17 22:01   ` Krzysztof Halasa
2012-10-17 22:01     ` Krzysztof Halasa
2012-10-19 16:25     ` Jason Cooper
2012-10-19 16:25       ` Jason Cooper
2012-10-29  8:29     ` Richard Cochran
2012-10-29  8:29       ` Richard Cochran
2012-10-30 22:27       ` Arnd Bergmann
2012-10-30 22:27         ` Arnd Bergmann
2012-10-31 13:24         ` Jason Cooper
2012-10-31 13:24           ` Jason Cooper
2012-10-29  9:55     ` Russell King - ARM Linux
2012-10-29  9:55       ` Russell King - ARM Linux
2012-10-30  0:46     ` Ryan Mallon
2012-10-30  0:46       ` Ryan Mallon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201210142002.55841.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=arm@kernel.org \
    --cc=khc@pm.waw.pl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.