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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
