On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote:

On Thu, 31 Mar 2011, Kevin Hilman wrote:

quoted

Thomas Gleixner [off-list ref] writes:

quoted

But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
to look at the overall picture, e.g reuse of code for the same IP
blocks, better abstraction mechanisms etc. 

zero incentive?  that's a bit strong, IMO.

That may be true for some SoCs, it's not really fair as a sweeping
statement.

Fair enough, but it's the perception in general.

quoted

Conference (ELC, US and Europe.)  Especially as IP blocks are reused
across SoC families, abstractions like runtime PM are the only way to
keep the SoC specifics of PM out of the common driver.

Right, I know that these things happen, but at the same time the sheer
amount of stuff flowing in makes it hard that these infrastructure
stuff really works out. And we are only at the beginning of the big
shuffle "code in to mainline" game.

After cleaning up the whole irq stuff across the tree I can tell you,
that the mess is non-linear growing with the number of instances.

You can see the patterns which are:
    - copy and paste
    - introduce different bugs
    - add more abuse

That's what I'm really concerned about.

quoted

Yes, ARM SoC maintainers have to make up some ground.  But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.

Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.

How about we declare the remainder of this cycle and the next merge window
as being only for bug and regression fixes, and consolidation of stuff like
the IRQ controller and GPIO controller code for the next merge window?