On Tue, 5 May 2015, Lu, Baolu wrote:Yes, that's right.
The order that software should do during device suspend/resume isBut _after_ all the URBs sent to the device have completed, right?
defined in 4.15.1.1 of xHCI spec 1.1.
Spec 4.15.1.1:
Software shall stop all endpoints of a device using the Stop Endpoint
Command and setting the Suspend
(SP) flag to 1 prior to selectively suspending a device.
The value of ringing door bell after resume is that hcd can fetch
After theThe driver would ring the endpoint's doorbell anyway when a new URB is
device is resumed software shall ring an
endpoint's doorbell to restart it.
submitted, wouldn't it? Which means the resume callback doesn't
actually have to do anything.
Yes, I agree with you. I will move the notification into usb_port_suspend(),
--end--You have forgotten that usb_port_suspend() can send URBs to the device
So the order looks like:
tell hcd device suspend
usb_port_suspend()
(to enable remote wakeup, for example). Therefore you shouldn't notify
the HCD until usb_port_suspend() is partly or totally finished.
Agree. I will do this within usb_port_resume() just after completing
usb_port_resume()You have also forgotten that usb_port_resume() calls various functions
tell hcd device resume
that send URBs to ep0 on the device. Therefore if the HCD's
device_resume callback needs to do something (like ringing ep0's
doorbell), you had better invoke the callback _before_ calling
usb_port_resume(). Or maybe you had better do this _within_
usb_port_resume().
Thank you for the comments. I will send the v2 patch series with all
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html