On Thu, Aug 5, 2010 at 7:34 AM, <david@xxxxxxx> wrote: > > for example, if you want to abort the suspend because there is network > activity, you can check the packet count of your network interface, decide > to go to sleep, setup the network interface to raise a 'wake me up' > interrupt (because you have decided in a userspace policy that you want > this), and then check to see if the packet count has changed. If it has, > abort the suspend, if not continue the suspend and once you are suspended if > the 'wake me up' interrupt is set you will wake back up. > > there are probably cleaner/better ways of doing this than the simple logic > that I'm listing, but why wouldn't the simple logic provide the correct > result? If your network interrupt happens before the network driver's suspend() hook is called this works -- the check in the suspend hook observes the change and returns an abort status. If your network interrupt happens after the suspend() hook is called this does not work -- the event comes after your opportunity to abort suspend has happened, your interrupt handler processed it, set the flag, but the system proceeds to suspend anyway, missing the event. The wakelock/suspendblock mechanism avoids races like the above. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
