On Thu, 2012-08-23 at 13:22 +0000, Arnd Bergmann wrote:

On Thursday 23 August 2012, Tony Prisk wrote:

quoted

quoted

On Thursday 23 August 2012, Tony Prisk wrote:

quoted

Without the clock patch (9/9), the mach-vt8500 patch (6/9) won't compile
due to unresolved symbols.

In arch/arm/mach-vt8500/vt8500.c - you will get an unresolved symbol
for 'vtwm_clk_init'

Not sure if this matters, thought I should point it out.
Does it need to compile cleanly in your tree (which is what I would assume),
or just once its all combined in -next?
Does it matter that the usb patches are already in -next?

I don't really understand the requirements around submitting to individual
trees and which (if any) of these points are actually issues.

The rule is that each changeset should be free of regressions compared
to the version before. So if you have a set of 7 patches in one branch
that you want me to pick up, the result after applying those 7 patches
should work, and each previous step should also work. You cannot for
instance add a call to a function in one patch and then provide that
function in the following patch.

There are multiple ways to achieve this:

* when you have dependencies, get everything merged through one
maintainer tree, and get Acks for each patch that belongs to another
maintainer.

* submit a branch with the patches that other stuff depends on to
both the subsystem maintainer who is responsible for it and to
the subsystem maintainer who gets the other patches that are built
on top of this branch. If you do this, you have to make sure that
the first branch never gets rebased and that the second branch is
not sent before the first one is upstream.

* change the code so that no dependencies exist, e.g. by introducing
a dummy implementation in one patch and the proper one in another.
This can generate merge conflicts, but that's usually ok.

	Arnd

I was about to say that if Mike has any issues with the driver that I
can fix the patch conflict at the same time, but I just realised that
its more work than I originally thought :)

I was going to move the arch-vt8500 part of the clocks patch back into
the clocks patch - but that will just move the issue from arm-soc to
clocks because Mike's branch won't have the arch-vt8500 patch so the
patch will fail.

If Mike is OK with it once the clocks driver is reviewed, it will be a
lot easier for the whole lot to go in via arm-soc, otherwise I can try
figuring out how to get the arch-vt8500 patch to Mike first, and then
the clocks patch.


Regards
Tony Prisk