Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend
From: Alan Cox <hidden>
Date: 2010-06-21 12:20:14
There's been one proposal that we simply merge in a set of no-op inline functions for suspend blockers, just so we can get let the drivers go in (assuming that Greg K-H believes this is still a problem), but with an automatical removal of N months (N to be decided, say 9 or 12 or 18 months).
If you automatically remove the suspend blocker wrappers in 12 months then you can keep the drivers in tree. The drivers are generally not a problem (ok some of them like the binder are interesting little trips) its just those hooks, and we'd all benefit somewhat even if the only bit google are patching back in are their hooks.
down the road for N months. Another approach is to simply merge in no-op functions and not leave any kind of deprecation schedule. That's sort of an implicit admission of the fact that we may not reach consensus on this issue. Or we could simply ship the patches as-is to
Very bad precedent. What happens when every other vendor does the same ? Keep the upstream code clean.
Linus after he gets back from vacation and ask him for a thumbs up or thumbs down vote, which might settle things once and for all.
You seem desperate to just throw it at Linus - you have been all along before the discussion, during it and now: but I don't understand why ? It's as if you don't want progress to be made by other means ?
How do we go forward from here?
PM QoS seems to be evolving nicely. As for merging stuff - if its new code then it should get submitted with the hooks left out anyway, just as all the other vendors are doing with weird little custom hooks of their own. The hooks can still easily be patched back in as a tiny easy to maintain vendor patch. This works - the code still gets updated and seen by people, only the little hook patch has to be maintained and generally it looks after itself except for the odd .rej when something changes right up by the merge point. Alan