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. > 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. > 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? cheers, -roger
