From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Olof Johansson <olof@lixom.net>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>
Cc: davinci-linux-open-source@linux.davincidsp.com,
linux-samsung-soc@vger.kernel.org, linux-sh@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: ARM/ARM-SoC plans for v3.4 merge window
Date: Mon, 30 Jan 2012 11:08:19 +0100 [thread overview]
Message-ID: <4F266C13.5080302@atmel.com> (raw)
In-Reply-To: <CAOesGMh45HSb4mRMc7q53xhmj_kMFvdVJhNnY7cY6gHi=_KynQ@mail.gmail.com>
On 01/29/2012 12:57 AM, Olof Johansson :
> Hi,
>
>
> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
>
>> And we're now there. So...
>>
>> Arnd, Olaf,
>>
>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>
>> git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>
>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>
> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>
> Any next/ branch we start will have this as the base of said branch,
> so any vendor branches must either already be developed against this
> stable branch, or merge on top of this with minimal conflicts.
Ok, great.
I just let you know that there is a conflict between the current Linus'
tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
I can give you the resolution of this conflict easily but I would like
to know which way I execute the merge:
I use this rmk/for-armsoc as a baseline and merge the fixes already in
Linus' tree on top of it or the other way around?
Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
on top of it. This result can be the base of our AT91 work for 3.4
preparation.
Your thought?
Best regards,
--
Nicolas Ferre
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: ARM/ARM-SoC plans for v3.4 merge window
Date: Mon, 30 Jan 2012 10:08:19 +0000 [thread overview]
Message-ID: <4F266C13.5080302@atmel.com> (raw)
In-Reply-To: <CAOesGMh45HSb4mRMc7q53xhmj_kMFvdVJhNnY7cY6gHi=_KynQ@mail.gmail.com>
On 01/29/2012 12:57 AM, Olof Johansson :
> Hi,
>
>
> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
>
>> And we're now there. So...
>>
>> Arnd, Olaf,
>>
>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>
>> git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>
>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>
> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>
> Any next/ branch we start will have this as the base of said branch,
> so any vendor branches must either already be developed against this
> stable branch, or merge on top of this with minimal conflicts.
Ok, great.
I just let you know that there is a conflict between the current Linus'
tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
I can give you the resolution of this conflict easily but I would like
to know which way I execute the merge:
I use this rmk/for-armsoc as a baseline and merge the fixes already in
Linus' tree on top of it or the other way around?
Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
on top of it. This result can be the base of our AT91 work for 3.4
preparation.
Your thought?
Best regards,
--
Nicolas Ferre
WARNING: multiple messages have this Message-ID (diff)
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM/ARM-SoC plans for v3.4 merge window
Date: Mon, 30 Jan 2012 11:08:19 +0100 [thread overview]
Message-ID: <4F266C13.5080302@atmel.com> (raw)
In-Reply-To: <CAOesGMh45HSb4mRMc7q53xhmj_kMFvdVJhNnY7cY6gHi=_KynQ@mail.gmail.com>
On 01/29/2012 12:57 AM, Olof Johansson :
> Hi,
>
>
> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
>
>> And we're now there. So...
>>
>> Arnd, Olaf,
>>
>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>
>> git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>
>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>
> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>
> Any next/ branch we start will have this as the base of said branch,
> so any vendor branches must either already be developed against this
> stable branch, or merge on top of this with minimal conflicts.
Ok, great.
I just let you know that there is a conflict between the current Linus'
tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
I can give you the resolution of this conflict easily but I would like
to know which way I execute the merge:
I use this rmk/for-armsoc as a baseline and merge the fixes already in
Linus' tree on top of it or the other way around?
Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
on top of it. This result can be the base of our AT91 work for 3.4
preparation.
Your thought?
Best regards,
--
Nicolas Ferre
next prev parent reply other threads:[~2012-01-30 10:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 11:49 ARM/ARM-SoC plans for v3.4 merge window Russell King - ARM Linux
2012-01-23 11:49 ` Russell King - ARM Linux
2012-01-23 11:49 ` Russell King - ARM Linux
2012-01-24 9:50 ` Russell King - ARM Linux
2012-01-24 9:50 ` Russell King - ARM Linux
2012-01-24 9:50 ` Russell King - ARM Linux
2012-01-24 10:56 ` Will Deacon
2012-01-24 10:56 ` Will Deacon
2012-01-24 10:56 ` Will Deacon
2012-01-24 11:27 ` Russell King - ARM Linux
2012-01-24 11:27 ` Russell King - ARM Linux
2012-01-24 11:27 ` Russell King - ARM Linux
2012-01-24 11:45 ` Will Deacon
2012-01-24 11:45 ` Will Deacon
2012-01-24 11:45 ` Will Deacon
2012-01-26 21:23 ` Russell King - ARM Linux
2012-01-26 21:23 ` Russell King - ARM Linux
2012-01-26 21:23 ` Russell King - ARM Linux
2012-01-28 23:57 ` Olof Johansson
2012-01-28 23:57 ` Olof Johansson
2012-01-28 23:57 ` Olof Johansson
2012-01-30 10:08 ` Nicolas Ferre [this message]
2012-01-30 10:08 ` Nicolas Ferre
2012-01-30 10:08 ` Nicolas Ferre
2012-02-08 1:18 ` Olof Johansson
2012-02-08 1:18 ` Olof Johansson
2012-02-08 1:18 ` Olof Johansson
[not found] ` <CAOesGMh1wHpaDmYY6_oCu_u0s4fmTfKMLiPaa9bHh9YaiDJozw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-02-08 11:52 ` Nicolas Ferre
2012-02-08 11:52 ` Nicolas Ferre
2012-02-08 11:52 ` Nicolas Ferre
2012-02-09 1:19 ` Olof Johansson
2012-02-09 1:19 ` Olof Johansson
2012-02-09 1:19 ` Olof Johansson
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=4F266C13.5080302@atmel.com \
--to=nicolas.ferre@atmel.com \
--cc=arnd@arndb.de \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--cc=plagnioj@jcrosoft.com \
--cc=sfr@canb.auug.org.au \
/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.