Conflict between Versatile Express DT conversion and local timer updates

On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:

On 13/03/12 01:23, Olof Johansson wrote:

quoted

Hi,

On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:

quoted

Marc, Pawel,

Your changes are conflicting badly.  Seriously badly.  So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.

You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves.  That's simply broken workflow.)

For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express.  The
correct solution?  Hell knows.  And I don't want a solution to the merge
conflict.  I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)

I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.

I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.

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.