Re: autosuspend for HID devices, take #2

Am Dienstag, 22. Mai 2007 16:59 schrieb Alan Stern:
> On Tue, 22 May 2007, Oliver Neukum wrote:
 
> On the other hand, I still think you'd be better off with only one
> spin_lock_irq() call in hid_suspend().  After all, you always have to
> synchronize with the error handler, no matter what kind of suspend it
> is.  In addition there would be nothing really wrong with calling
> usbhid_wait_io() for an autosuspend, since it should return right
> away.  If you follow this advice, you'll find that the two branches
> share quite a lot more code than they do now.

I'll think about it.
 
> > TODO
> > 
> > - pre/post_reset is currently broken, it can no longer be a parasite
> >   on suspend/resume
> 
> Why not?  The only difference I can see is that you're allowed to fail 
> a suspend but not a pre_reset.

Yes, but if you are in pre_reset, chances are something is wrong
with the devices. Outright slaughter of all outstanding URBs is better
than waiting for them to complete.
 
> In fact, failing a non-auto suspend is not a good idea.  You could 
> easily end up preventing somebody's laptop from hibernating when they 
> close the lid and put it in their knapsack.

Yes, and I don't. That's one reason I want to separate the auto and system
cases. 

> > - adapt to hibernate
> 
> What adaptations are needed?

Do I need to kill remote wakeup?
 
> > There is a principal issue. What is to be done with output requests?
> > Starting the queue as soon as one arrives seems the safest thing to do,
> > but it is fatal in a subset of situations, that is, it must not be done during
> > snapshotting and when going for system suspend. The freezer is insufficient
> > to prevent new requests from coming in.
> 
> Because new requests are generated as a result of interrupt processing.  

Yes.

> But if you kill the interrupt URB then there will be no more inputs and
> hence nothing to generate any more output.  Thus, when suspending you
> should kill the inputs and wait for the outputs to drain (or else
> explicitly plug the output queue).  Then it will be safe to autoresume
> whenever a new output queue entry arrives.

Nope. Devices share LED status. Now think of the case of having two
keyboards, one already processed and the other still active.

> Come to think of it, it would be safest to have an explicit way of 
> plugging the queues.  But those details are up to you.

What tells me when to do so?

> > Alan, are you going to scream and leap with talons extended if I
> > suggest yet another pair of methods for USB devices to facilitate
> > that?
> 
> Probably.  Besides, it's not just a USB problem.  Other drivers -- and
> also some kernel threads -- will need to know when a hibernation is
> about to start.  Isn't there going to be a notifier chain added for 
> this?

I have no idea. Should I ask on the pm list?

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel