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
