On 17/02/2023 00:23, Thinh Nguyen wrote: > 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 for the confirmation. I will do some tests in this area and get back when I have some results to share. cheers, -roger
