David:
The UHCI driver clearly has a problem with its reset/start/suspend/resume/stop functions. I'm not sure how to fix it because it's not clear exactly what the callbacks are supposed to accomplish and the contexts in which they are called (most especially whether they are allowed to block). The comments in core/hcd.h are very terse.
Look more at where they're called: hcd.c, hcd-pci.c ... All are allowed (even expected!) to block (schedule), like their callers.
A couple of additional questions suggest themselves. First, what should happen if a wakeup/resume signal on the USB bus is detected before the suspend routine returns?
We seem to have adopted the policy that going into system suspend means going into USB suspend ... but USB suspend could happen at other times, it's just "idle bus" (no SOF generation or other traffic) that lets devices save power (battery etc) and lets the host avoid accessing memory (scanning schedule etc).
Since nothing turns on remote wakeup with USB, I'm suspecting we shouldn't be expecting resume signaling. (And should be cautious about suspending any port with a device on it.) But I've not dived particularly into that chunk of USB.
Once we do support remote wakeup, that question gets real. Maybe we can fail the suspend operation; or maybe it'll get handled like a normal remote wakeup would.
Second, the Intel UHCI controllers have an erratum which causes them to present spurious resume-detect signals if a port's over-current input is active. (This is not just a theoretical problem; some manufacturers don't wire up all of the ports to connectors and then try to disable the unconnected ports by permanently tying the over-current inputs on.) When this happens the driver makes the conservative choice and does not allow suspends at all -- it will shutdown but not suspend. How should the PM callbacks behave in that situation?
Scanning uhci docs suggest resume-detect is part of its remote wakeup support. Yes?
And since Linux-USB doesn't seem to enable the remote wakeup feature in any device, we have no reason to pay attention to such requests. They're all errors, unless/until the host enables remote wakeup for some device accessed through that root hub port.
- Dave
Alan Stern
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
