On Thu, Feb 16, 2023, Alan Stern wrote: > On Thu, Feb 16, 2023 at 06:11:36PM +0000, Thinh Nguyen wrote: > > On Thu, Feb 16, 2023, Roger Quadros wrote: > > > I could not find any reference to 500ms time limit for suspend/resume case. > > > The only mention of 500ms in USB2.0 spec is: > > > > > > 9.2.6.4 Standard Device Requests > > > ... > > > For standard device requests that require data stage transfer > > > to the host, the device must be able to return the first data > > > packet to the host within 500 ms of receipt of the request. > > > For subsequent data packets, if any, the device must be able to > > > return them within 500 ms of successful completion of the > > > transmission of the previous packet. The device must then be > > > able to successfully complete the status stage within 50 ms after > > > returning the last data packet. > > > > > > I don't think this applies to suspend/resume. > > It's not specific to suspend/resume; it's a generic time limit. It can > vary depending on the application or the driver. > > > Are you referring to the handshake timeout when the host tries to > > initiate resume at the link layer? It's relatively short compare to the > > software timeout and will vary depending on how many hub tiers in the > > topology. Also, that's handled by the host and device controller. We > > should care more about the software timeout after resume completed. The > > 500ms here applies if the device couldn't resume fast enough for the > > driver to prepare a transfer response to the host. > > Also, keep in mind that we can increase the initial timeout limit > following a resume, if necessary (on Linux hosts with a recent kernel -- > obviously not on other kinds of hosts). Or make it an adjustable > parameter. > > > > > IMO, the system suspend on the gadget side should take precedence. That > > > > is, it shouldn't depend on whether the usb gadget is in suspend or not > > > > to go through system suspend. For that to happen, the gadget must > > > > initiate soft-disconnect. Otherwise I can see we may run into > > > > complications from the delay from the system suspend. For example, what > > > > if the host initiates resume right after suspend while the gadget side > > > > is still suspending? > > > > > > In this case, system will go all the way to suspend and then wake up. > > > It will take a few seconds more to respond than if system was already suspended. > > > > Yes, my concern is the suspend/resume is measured in seconds. > > It the gadget is too slow in responding, it shouldn't be a big deal. > The host will assume the gadget has disconnected and then will > re-discover it. Pretty much the same as if the gadget had actually > disconnected from the bus before going into system suspend. > It may not be the same. The host may try to recover and reset the device. If it fails after a few tries, it will stop communicate with the device until the next port change event. So the worst possible case would require the user to reconnect the device to trigger a port change event for the host to respond and reconnect the device. I'm not sure how easy it can get to that point. This requires some testings. BR, Thinh
