Re: Drivers without suspend/resume/reset-resume support

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
On Sat, 13 Oct 2007, Tilman Schmidt wrote:

> Am 12.10.2007 07:54 schrieb Oliver Neukum:
> > You cannot expect full function from a driver that doesn't support the
> > full API. If a driver doesn't support suspend/resume, by definition it
> > doesn't care or is buggy.
> 
> The two USB drivers in drivers/isdn/gigaset would arguably fall into
> the second category. I would love to fix that but have been unable
> to find the necessary information on the suspend/resume API. I have
> read Documentation/power/devices.txt but much of it just refers me
> to bus specific mechanisms.
> 
> Is there any documentation available that would tell me which
> methods I have to implement and what to do in them, specifically
> in the context of USB and ISDN?

A new file was just added: Documentation/usb/power-management.txt.  It 
answers some of your questions; I don't know about the ISDN issues.

> Wrt USB, I already gathered from past discussions that outstanding
> URBs are not handled gracefully across a suspend and should therefore
> be cancelled before suspending and resubmitted afterwards. Is that
> all?

Pretty much.  You should also do whatever is necessary to prevent the
upper layers from sending I/O requests to your driver (block queues,
tell it the driver is suspended, and so on).

> What about altsettings?

Altsettings will remain unchanged.

> What about devices plugged or unplugged
> during the suspend?

Your driver will be notified after the resume.

> Wrt ISDN, should my driver inform the isdn4linux subsystem if it
> gets suspended, and if so, how?

I can't answer that, not knowing anything about how isdn4linux works.

> Is there a clear policy how to handle ongoing activity such as an
> established dial-up connection in the case of a suspend request?
> Just "pull the plug"? Take the time to do an orderly hangup?
> Refuse to suspend while there is still a connection? Can/should
> that decision depend on the type of event triggering the suspend?
> (user request, idle time, low battery)

Such questions are best answered on a networking mailing list.

Your driver won't know much about the type of event triggering the 
suspend.  Mainly you will know whether or not it is an autosuspend (but 
if your driver doesn't support autosuspend anyway, then it won't be).

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.