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

[Roger Quadros <rogerq@kernel.org>]

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