Re: suspending hid devices
Oliver Neukum <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Message-ID | <[email protected]> |
Am Dienstag, 30. Januar 2007 17:28 schrieb Alan Stern: > On Tue, 30 Jan 2007, Jiri Kosina wrote: > > > On Mon, 29 Jan 2007, Oliver Neukum wrote: > > > > > > thanks, I think that basically killing output URBs is a good thing to do, > > > I've looked further and the control URB will have to die, too. > > > > Correct. > > > > > > however the resuming will need some more thinking. What are all the > > > > scenarios you can see that waiters on hid->wait will be woken too early? > > > 1) Resubmitting the IO upon resume() fails, error must be reported > > > 2) The output transfer finishes before tasks are unfrozen > > > > I think that creating a notifier chain which will be called in > > thaw_processes() after all the processes are unfrozen, will solve this > > problem, right? > > Do you really need to do all this? Shouldn't it be true, when you first > do the suspend, that all the I/O queues are empty? And since all tasks > are frozen and class drivers are suspended, no more I/O entries can be > created? It is impossible that more entries are created, yes. However, if you want this, suspend() has to wait for the queue to drain. This raises two other issues. 1. The tasks are already frozen, what will wake_up() do? 2. How long may the transfers last? Queue depth * control message timeout is a rather bad worst case to block in suspend(). Furthermore, what about input? It seems to me that it also can call wake_up()? Is this a specific limitation of suspend2? Regards Oliver ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel