> No, it's not. Forced suspend may be in response to hitting a key, but it You are the only person here talking about 'forced' suspends. The rest of us are talking about idling down and ensuring we are always in a state we un-idle correctly. > may also be in response to a 30 minute timeout expiring. If I get a WoL > packet in the 0.5 of a second between userspace deciding to suspend and > actually doing so, the system shouldn't suspend. I don't think that argument holds water in the form you have it What about 5 nanoseconds before you suspend. Now you can't do that (laws of physics and stuff). So your position would seem to be "we have a race but can debate how big is permissible" The usual model is "At no point should we be in a position when entering a suspend style deep sleep where we neither abort the suspend, nor commit to a suspend/resume sequence if the events we care about occur" and that is why the hardware model is Set wake flags Check if idle If idle Suspend else Clear wake flags Unwind and the wake flags guarantee that an event at any point after the wake flags are set until they are cleared will cause a suspend to be resumed, possibly immediately after the suspend. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
