Conflict between Versatile Express DT conversion and local timer updates

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

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:
> >> On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:
> >>> 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.