[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
> > Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> > have no desire to create an out-of-tree dependency if we can avoid it.
> > It has a habit of going horribly wrong [1].
> > 
> > I'll cherry-pick
> > 
> >   0c1dcfd clocksource: Add Marvell Orion SoC timer
> 
> Don't do that. Do a git fetch on that branch and then git merge
> 0c1dcfd.

> The patches before that Marvel commit are already in Linus tree. That
> way it does not matter who sends first or not.

ahh, ok.  I see your point now, thanks.

Daniel, do you mind tagging that commit, eg 'mvebu-deps-3.12' or
similar?

> Also for the next merge window: Can we please let everything under
> drivers/clocksoure go through Daniels and my trees?

Of course, that's what I've been encouraging:

http://permalink.gmane.org/gmane.linux.ports.arm.kernel/242342

""" Using Thomas Petazzoni's quoting style here :)

Is there a reason why the following breakdown wouldn't work?

>  arch/arm/boot/dts/armada-370-xp.dtsi     |   1 +
>  arch/arm/boot/dts/armada-370.dtsi        |   1 +
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |   1 +

through mvebu/arm-soc

>  arch/arm/mach-mvebu/Kconfig              |   1 +

through mvebu/arm-soc after the other three have landed (v3.11-rc1)

>  drivers/irqchip/irq-armada-370-xp.c      | 186 ++++++++++++++++++++++++++++++-

through tglx

>  drivers/pci/host/pci-mvebu.c             |  21 ++++
>  drivers/pci/msi.c                        |  59 +++++++++-
>  drivers/pci/probe.c                      |   1 +
>  include/linux/msi.h                      |  22 ++++
>  include/linux/pci.h                      |   1 +

through Bjorn

I think we should view the manner in which we brought in the initial
mvebu-pcie series (all through arm-soc) as the exception, not the rule.
I have no problem, and in fact, prefer to have them reviewed as a
series, but if at *all* possible, the series should be structured so
relevant maintainers can pick up the relevant patches into their trees.

""" End quote

There's a delicate three-way balance between pushing patches that we
depend on to the appropriate maintainers, avoiding out-of-tree
dependencies for arm-soc, and keeping the ball moving.

I don't mind delaying half of a series so the drivers/ portion can land
in mainline, and the rest can land in the next cycle.  But when things
don't go according to that plan, I'd like a little consideration /
flexibility about solving the problem.  Especially considering I'm
*trying* to do the right thing by pushing to appropriate maintainers
first.

Of course, this is a moot point since, as you clarified above, this
dependency doesn't have the hazards typically associated with
out-of-tree dependencies.

thx,

Jason.