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