Re: [markgross@thengar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

On Sat, 15 Oct 2011 21:49:44 -0400 (EDT) Alan Stern
<stern@rowland.harvard.edu> wrote:


> All right, let's make things a little more complicated.

Let's call it "realistic".   It is good to have some realism to make sure our
abstract discussions actually mean something.

> 
> Here's what actually happens when a USB keyboard generates a wakeup 
> request.  The system wakes up, of course, but there's no particular 
> indication of the cause.  In particular, the usbhid driver has no way 
> to know directly that the keyboard was the reason for the wakeup.
> 
> In addition, usbhid can't poll keyboards to see if they have an event
> to report.  (In theory it could -- the HID protocol allows for this --
> but many keyboards don't support that part of the protocol properly.)  
> It has to wait until the keyboard gets around to reporting the event, 
> which can take 10 ms or more.
> 
> Taken together, this means usbhid must activate a wakeup_source every
> time it wakes up.  If a keyboard event report is received reasonably
> quickly then good, it can deactivate the wakeup_source at the right
> time.  But if not, all the driver can do is time out the wakeup_source
> after some delay.  I don't see any way to avoid it.

I have to agree with you there.
This is similar to Rafael's example of a Wake-on-LAN packet arriving.  At
that point there is nothing you can do except wait a little while expecting
more information.

You could see this as a case where the wake-up event isn't even visible to
the kernel, so there is obviously no way to make it visible to user-space.

Or you could see it as a wake-up event that is expected to be delivered over
a long period of time (many msecs).  The kernel gathers the wake-up event,
makes it visible to user-space (once it actually arrives), and then releases
the wakeup_source.

So it is a good example and highlights the difficulty of defining exactly
what a wake-up event it, and of what it means to be "visible".

I think it still fits in your rephrasing of my question which - if I rephrase
it as a requirement - is roughly,

  A wakeup-event that needs to be handled by user-space must be visible to
  user-space before the driver deactivates the wakeup_source.

A requirement which, in this case, means the driver needs to hold  the
wakeup_source for an extended time using a timeout, just as you say.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]