Re: suspending hid devices

On Tue, 30 Jan 2007, Oliver Neukum wrote:

> > 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.

Yes.  Or else it has to stop sending URBs, as in your patch.

> This raises two other issues.
> 1. The tasks are already frozen, what will wake_up() do?

Nothing.  The task will remain frozen.  When it is unfrozen it will see 
that an event has occurred.

There's nothing special about this.  The same conditions are in effect 
after the tasks have been frozen, before the HID driver is suspended.

> 2. How long may the transfers last? Queue depth * control message timeout
> is a rather bad worst case to block in suspend().

You're probably right that it's better to stop the queue than to wait for 
it to drain.

> Furthermore, what about input? It seems to me that it also can call wake_up()?

You mean the control-IN queue?  Same thing: either stop the queue or wait 
for it to drain.

> Is this a specific limitation of suspend2?

What do you mean?

Alan Stern


-------------------------------------------------------------------------
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