Re: [PATCH 00/16] Omap2 patches for post 2.6.26

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Fri, Jun 06, 2008 at 06:47:41PM -0700, Tony Lindgren wrote:
> This patch series contains various omap2 patchs from linux-omap tree.
> Big chunk of the patches still improve the clock code. Also more
> clean-up to allow compiling omap2 and omap3 support into the same
> kernel. The patch also adds core omap3430 support, but no board
> files or PM at at this point.

Apart from the comments I've made, the rest seem "fine" as far as I can
tell.

There's a _lot_ of churn in there, some of which is caused there not
being sufficient review of the OMAP code before it was merged into
mainline.  Such things as:

	if (unlikely((u32)clk->parent))

stick out like a sore thumb.  And that's a direct result of me getting
to the point of "tonnes more omap churn, sod it, I'm just going to
apply this."

If the (considerable) upstream workload is going to be reduced to an
acceptable level, people further downstream need to take on board that
they have a certain element of responsibility with their patches to
ensure that they are acceptable _before_ they hit any of these git
trees.

That also means sometimes combining two or more patches before it goes
upstream - in other words, what's visible to mainline is the "finished
product" of development of a new feature _without_ all the historical
baggage associated with it.

That said, I'll probably guess that you are completely overloaded by
the amount of work coming out of the OMAP trees themselves and can't
keep up with it either, so you're probably doing the best you can.  I
can well believe that now that I have visibility of how the various
OMAP trees are structured.

Eg, I don't think you have any way to apply any pressure to downstream
people to encourage them to only submit tested patches - because the
"downstream people" is just another tree ?