On Thu, Aug 5, 2010 at 7:34 AM,  <david@lang.hm> wrote:
quoted text
>
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/