Re: [linux-pm] suspend blockers & Android integration

[Christoph Hellwig <hch@infradead.org>]

On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote:
> I was shocked when Greg pulled the binder driver and some of the other
> "generic" android drivers into staging, because it was always my
> assumption that nobody upstream would want them.  We did get some
> bugfixes for the binder driver (thanks!) but the general reaction was
> pretty much the same as yours here.  I then was relatively unsurprised
> when it was dropped (we find it useful, upstream finds it useless, not
> much else to say).
> 
> The various SoC peripheral drivers are, I suspect, much less
> contentious (modulo suspend blocker usage and any necessary kernel
> style cleanup).

Yes.  That's what makes me wonder about some parts of the discussion
here.  Getting the drivers for one or more of the android plattforms
in is not a problem.  I'd say it could have easily been done with the
manweeks spent arguing in this and related threads.

The much bigger issues is to get android userspace running on a more
or less vanilla kernel, that is withoutthe  binder, without the rather
interesting group ID based security hack^H^H^H^Hmodel, without the
suspend blocker userspace API and so on, and so on.

So for people who really care about running a mainline kernel on their
android device doing that part first on a generic ARM board in qemu
might be much better first step work.   On the other hand I've heard
that various hardware vendors or parties closed to them are rather
annoyed by their drivers beeing stuck in the android tree - but that
can be easily solved by getting removing the suspend blockers (at least
temporarily), cleaning up a few bits here and there and getting them in.

It's not rocket science to get support for ARM SOC number 1654 into the
mainline kernel.