On Tue, 22 May 2007, Oliver Neukum wrote: > > > 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.
Fair enough. I wouldn't call post_reset "broken", though. > > 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. What happens if usbhid_wait_io() times out? > > > - adapt to hibernate > > > > What adaptations are needed? > > Do I need to kill remote wakeup? No. It should be handled at a higher level. (Right now we don't really handle it properly; this is partly the fault of the PM core.) > > > 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. Yes, I had forgotten. Then you will have to rely on plugging. > > 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? The best you can do is to plug the queues whenever you do a non-auto suspend. But that won't help if the device is already autosuspended when a hibernate begins. This is a good question; we should bring it to the attention of the PM people. > > > 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? Go ahead. It's connected to the previous question. Be sure to include enough details to make the nature of the problem clear to everyone, even people not familiar with the input subsystem. Alan Stern ------------------------------------------------------------------------- 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
