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

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

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