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/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
