From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Conflict between Versatile Express DT conversion and local timer updates
Date: Tue, 13 Mar 2012 11:55:16 +0000 [thread overview]
Message-ID: <201203131155.16454.arnd@arndb.de> (raw)
In-Reply-To: <4F5F2859.5020407@arm.com>
On Tuesday 13 March 2012, Marc Zyngier wrote:
> On 13/03/12 10:15, Russell King - ARM Linux wrote:
> > On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
> >> On 13/03/12 01:23, Olof Johansson wrote:
> >>> Hi,
> >>>
> >>> On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
> >>> <linux@arm.linux.org.uk> wrote:
> >>>>
> >>>> Correction: I haven't been pushing out my devel-stable branch for
> >>>> apparantly two months (according to gitweb, and no one noticed?), so I
> >>>> could drop the merge of Marc's tree until the conflicts can be sanely
> >>>> resolved.
> >>>
> >>> I haven't noticed because I stopped tracking your tree directly when
> >>> you were having server load issues; I tend to have kept an eye on
> >>> linux-next-level breakage instead, but probably not as close as I
> >>> should have.
> >>>
> >>> Dropping Marc's branch and having him either resubmit on top of
> >>> arm-soc like the io cleanup was done, or pull it in as an early
> >>> dependency for 3.5 and stage it in an for-armsoc branch sounds like
> >>> two good options to me, with no real preference in either direction.
> >>
> >> I'm happy to rebase my patches on anything that will make the merge
> >> easier (IOW conflict-less).
> >>
> >> Russell, would you prefer this series to go via armsoc? This seems the
> >> cleanest solution for the time being.
> >
> > With a lot of these core ARM changes, there's a very fine line between
> > whether they are core ARM changes or whether they're platform level
> > changes (many core ARM changes will impact lots of platforms.) I'm just
> > wondering if there's any point to taking these changes through my tree.
> > It seems utterly pointless if they're going to keep conflicting with
> > platform stuff.
>
> Fair enough.
>
> Olof, Arnd: which is the most base for you to take this series?
I'm not sure I understand your question. The conflicts that Russell
mentioned are with the ux500/timer (in next/soc) and with the
vexpress/dt (in next/dt) branches. There are multiple ways out of
here:
a) take your series first, but merge it into the next/dt and next/soc
branches, resolving the conflicts in the process. This would be
fairly easy to do if you can provide the merge resolution as
a git pull and let Russell still take your series as is.
b) rebase your series on top of vexpress/dt, merge it into the next/soc
branch.
c) rebase your series on top of ux500/timer, merge it into the next/dt
branch.
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Arnd
next prev parent reply other threads:[~2012-03-13 11:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 23:10 Conflict between Versatile Express DT conversion and local timer updates Russell King - ARM Linux
2012-03-12 23:59 ` Russell King - ARM Linux
2012-03-13 1:23 ` Olof Johansson
2012-03-13 9:39 ` Marc Zyngier
2012-03-13 10:15 ` Russell King - ARM Linux
2012-03-13 10:58 ` Marc Zyngier
2012-03-13 11:55 ` Arnd Bergmann [this message]
2012-03-13 13:58 ` Marc Zyngier
2012-03-13 14:33 ` Arnd Bergmann
2012-03-13 15:00 ` Marc Zyngier
2012-03-14 0:52 ` Olof Johansson
2012-03-14 8:43 ` Marc Zyngier
2012-03-15 7:17 ` Stephen Rothwell
2012-03-15 9:21 ` Russell King - ARM Linux
2012-03-15 9:36 ` Russell King - ARM Linux
2012-03-15 9:44 ` Stephen Rothwell
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=201203131155.16454.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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.