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

[mark gross <markgross@thegnar.org>]

Sorry for going AWOL on this thread.  I had some biz travel and fires to
fight.

On Mon, Oct 17, 2011 at 08:37:17AM +1100, NeilBrown wrote:
> 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.

Timeout?  why can't we define a proper notification handshake for such
things?  Timeouts are never right IMO.

--mark



> Thanks,
> NeilBrown