Re: dwc3: gadget suspend/resume vs system suspend/resume

[Alan Stern <stern@rowland.harvard.edu>]

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