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

Previous thread: [PATCH v4] mtd: Do not corrupt backing device of device node inode by Kirill A. Shutemov on Wednesday, May 5, 2010 - 8:40 am. (4 messages)

Next thread: Re: [linux-pm] [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E) by Alan Stern on Wednesday, May 5, 2010 - 8:55 am. (3 messages)
From: Alan Stern
Date: Wednesday, May 5, 2010 - 8:44 am

The second part is easy.  Userspace doesn't need to do anything special 
to acknowledge that a suspend is now okay; it just has to remove the 
conditions that led the driver to block suspends in the first place.

For example, if suspends are blocked because some input event has been

Why?  What's wrong with overlapping blockers?  It's a very common
idiom.  For example, the same sort of thing is used when locking
subtrees of a tree: You lock the root node, and then use overlapping

Userspace acks aren't the issue; the issue is how (and when) kernel 
drivers should initiate a blocker.  Switching to notifications, misc 

No and no.  Nothing special is needed.  All userspace needs to do is 
remove the condition that led to the blocker being enabled initially -- 
which is exactly what userspace would do normally anyway.

Alan Stern

--

From: mark gross
Date: Wednesday, May 5, 2010 - 1:28 pm

Because in the kenel there is only a partial ordering of calling
sequences from IRQ to usermode.  I see a lot of custom out of tree code
being developed to deal with getting the overlapping blocker sections

communicating non-local knowledge back down to the blocking object to

Oh, like tell the modem that user mode has handled the ring event and
its ok to un-block?

--mgross
--

Previous thread: [PATCH v4] mtd: Do not corrupt backing device of device node inode by Kirill A. Shutemov on Wednesday, May 5, 2010 - 8:40 am. (4 messages)

Next thread: Re: [linux-pm] [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E) by Alan Stern on Wednesday, May 5, 2010 - 8:55 am. (3 messages)