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

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

On Thu, Feb 16, 2023, Roger Quadros wrote:
> 
> 
> On 16/02/2023 20:11, Thinh Nguyen wrote:
> > On Thu, Feb 16, 2023, Roger Quadros wrote:
> >>
> >>
> >> On 16/02/2023 00:53, Thinh Nguyen wrote:
> >>> On Wed, Feb 15, 2023, Alan Stern wrote:
> >>>> On Wed, Feb 15, 2023 at 07:29:52PM +0200, Roger Quadros wrote:
> >>>>> I was more interested in this case where USB is suspended and then system suspends.
> >>>>> Waking up the system on USB activity (while suspended) is taken care of by hardware.
> >>>>> But I'm not sure if gadget driver will be up in time to respond to the request
> >>>>> reasonably quickly. It would take a couple of seconds and is not hard time bound.
> >>>>> Is this time mandated by the USB Spec or is it host implementation specific?
> >>>>
> >>>> The USB spec doesn't say very much about it.  One part of the USB 2.0 
> >>>> spec seems relevant; it says:
> >>>>
> >>>> 	9.2.6.2 Reset/Resume Recovery Time
> >>>>
> >>>> 	After a port is reset or resumed, the USB System Software is 
> >>>> 	expected to provide a “recovery” interval of 10 ms before the 
> >>>> 	device attached to the port is expected to respond to data 
> >>>> 	transfers. The device may ignore any data transfers during the 
> >>>> 	recovery interval.
> >>>>
> >>>> 	After the end of the recovery interval (measured from the end 
> >>>> 	of the reset or the end of the EOP at the end of the resume 
> >>>> 	signaling), the device must accept data transfers at any time.
> >>>>
> >>>> Accepting a data transfer doesn't necessarily mean completing it, 
> >>>> though.  The Linux USB core does send a request to a device 10 ms 
> >>>> after resuming it, but the timeout period on this request is 5 seconds.  
> >>>> This gives you some leeway.
> >>>>
> >>>
> >>> For most standard control requests, the spec indicates that the device
> >>> must respond within 500ms. But that's not the case for some real devices
> >>
> >> 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.
> > 
> > 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.
> > 
> >>
> >>> so we have a 5 second timeout in Linux. For other requests, it's up to
> >>> the class drivers. For most drivers on Linux, it's typically 5 seconds
> >>> also.
> >>
> >> So it looks doable with Linux host. I'll have to check how other
> >> USB hosts behave.
> >>
> >>>
> >>> 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.
> > 
> >>
> >>> What if there are other gadgets on the setup that
> >>> want or not want to go to suspend also? How can the system decide when
> >>> it can go into suspend then?
> >>
> >> I think this is a policy decision and we cannot force one way or the other
> >> in the kernel but allow user space to decide what must be done.
> >> It would really depend on what the end application needs.
> >>
> >> So, does a gadget specific user settable flag seem reasonable to decide
> >> if gadget driver should:
> >> a) disconnect on system suspend regardless of USB state (current behavior)
> >> b) prevent a system suspend if gadget is not in USB suspend. Allow otherwise.
> >>
> >> Or any better ideas?
> >>
> > 
> > What's the use case here? Are you trying to drive the gadget system
> > suspend via the host? That is, if the host resumes, the system on the
> > gadget side would resume also? If that's the case, then perhaps that can
> > be triggered in the gadget driver suspend instead?
> 
> The use case is:
> The Linux System is a USB gadget which
> 1) If plugged to USB host and USB gadget is active the system will remain active
> 2) If plugged to USB host and USB gadget is suspended, it can transition to system suspend
> (but may not always) (this check and trigger to system suspend is user space driven)
> 3) If system has suspended, any USB activity should resume the system and USB gadget should
> resume (preferably without a disconnect/re-enumeration)
> There can be exceptions if we don't meet certain host software timeout criteria,
> in which case we simply re-enumerate.

I see.

> 
> > 
> > Otherwise, it makes more sense to let the user control when he/she wants
> > to resume if the user is the one that triggers the system suspend. On
> > resume, the connection can be reestablished.
> 
> This is how it already is now no?

Yes, that's the current behavior.

Thanks for the clarification on the use case. I think it makes sense if
you want to change the current behavior for this. However this requires
some testings.

Thanks,
Thinh