Re: [PATCH 1/8] PM: Add suspend block api.

Alan Stern
2010-05-04T13:59:59Z

On Mon, 3 May 2010, mark gross wrote:

> You know things would be so much easier if the policy was a one-shot
> styled thing. i.e. when enabled it does what it does, but upon resume
> the policy must be re-enabled by user mode to get the opportunistic
> behavior. That way we don't need to grab the suspend blocker from the
> wake up irq handler all the way up to user mode as the example below
> calls out. I suppose doing this would put a burden on the user mode code
> to keep track of if it has no pending blockers registered after a wake
> up from the suspend. but that seems nicer to me than sprinkling
> overlapping blocker critical sections from the mettle up to user mode.
>
> Please consider making the policy a one shot API that needs to be
> re-enabled after resume by user mode. That would remove my issue with
> the design.

This won't work right if a second IRQ arrives while the first is being
processed. Suppose the kernel driver for the second IRQ doesn't
activate a suspend blocker, and suppose all the userspace handlers for
the first IRQ end (and the opportunistic policy is re-enabled) before
the userspace handler for the second IRQ can start. Then the system
will go back to sleep before userspace can handle the second IRQ.

Alan Stern