Re: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
From: Jason Cooper
Date: Sun Jul 07 2013 - 19:59:05 EST
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/