On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: > > > Because someone would have to remove suspend blockers (or rather wakelocks) > > from the drivers, test that they work correctly without suspend blockers and > > submit the modified versions. Going forward, every party responsible for > > such > > a driver would have to maintain an out-of-tree version with suspend blockers > > (or wakelocks) anyway, so the incentive to do that is zero. > > They should work without wakelock since wakelock are optional .. I mean > there's nothing in suspend blockers I've seen that indicates it's > required for some drivers to work. So it's just a matter of patching out > the wakelocks, with no need to re-test anything. > > You get the driver mainlined, then maintain a small patch to add > wakelocks. Not hard at all , with lots of incentive to do so since you > don't have to maintain such a large block of code out of tree.
Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
