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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
