dwc3: gadget suspend/resume vs system suspend/resume

dwc3: gadget suspend/resume vs system suspend/resume

[Roger Quadros]

Hi Thinh,

Currently dwc3 gadget disconnects from the bus in the system suspend path. i.e. dwc3_gadget_suspend()->dwc3_disconnect_gadget().

Is it reasonable to expect dwc3 gadget to do a USB suspend instead of a USB disconnect during system suspend?
At USB resume, system can wake up and resume and then dwc3 gadget can resume.

I'd like to know your opinion please if this is a reasonable expectation or something just not possible to achieve. Thanks!

cheers,
-roger

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

[Alan Stern]

On Wed, Feb 15, 2023 at 11:40:15AM +0200, Roger Quadros wrote:
> Hi Thinh,
> 
> Currently dwc3 gadget disconnects from the bus in the system suspend 
> path. i.e. dwc3_gadget_suspend()->dwc3_disconnect_gadget().
> 
> Is it reasonable to expect dwc3 gadget to do a USB suspend instead of 
> a USB disconnect during system suspend?

Gadgets can't initiate a USB suspend.  Only the host can.

Did you mean to ask the opposite question?  I.e., is it reasonable for a 
dwc3 gadget to go into system suspend when it gets a USB suspend?

In general, it's easiest for gadgets to disconnect from the USB bus when 
their system suspends, if they aren't already in USB suspend.  This is 
because they would be unable to respond to requests from the host while 
sleeping.

> At USB resume, system can wake up and resume and then dwc3 gadget can 
> resume.
> 
> I'd like to know your opinion please if this is a reasonable 
> expectation or something just not possible to achieve. Thanks!

There can be exceptions, but it's a dicey thing.  The UDC hardware would 
have to be able to send handshake packets back to the host while 
remaining in low power, it would have to be able to generate a wakeup 
signal to bring its system back to full power, and the system would have 
to be able to resume in time for the gadget to respond to a request from 
the host before the request times out.

The situation is different if the gadget is already in USB suspend.  
Then it only needs to be able to wake up its system when it gets a USB 
resume signal.  But the system would still have to wake up reasonably 
quickly.

Alan Stern

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

[Roger Quadros]

On 15/02/2023 17:41, Alan Stern wrote:
> On Wed, Feb 15, 2023 at 11:40:15AM +0200, Roger Quadros wrote:
>> Hi Thinh,
>>
>> Currently dwc3 gadget disconnects from the bus in the system suspend 
>> path. i.e. dwc3_gadget_suspend()->dwc3_disconnect_gadget().
>>
>> Is it reasonable to expect dwc3 gadget to do a USB suspend instead of 
>> a USB disconnect during system suspend?
> 
> Gadgets can't initiate a USB suspend.  Only the host can.
> 
> Did you mean to ask the opposite question?  I.e., is it reasonable for a 
> dwc3 gadget to go into system suspend when it gets a USB suspend?

Yes. Thanks for correcting. ;)

> 
> In general, it's easiest for gadgets to disconnect from the USB bus when 
> their system suspends, if they aren't already in USB suspend.  This is 
> because they would be unable to respond to requests from the host while 
> sleeping.

Oh in that case the gadget driver will have to prevent a system suspend till
the gadget is put into USB suspend by the USB host.
I think this is a reasonable expectation. It could be an application specific
requirement. i.e. whether to disconnect on system suspend or wait
for USB suspend before system suspend.


> 
>> At USB resume, system can wake up and resume and then dwc3 gadget can 
>> resume.
>>
>> I'd like to know your opinion please if this is a reasonable 
>> expectation or something just not possible to achieve. Thanks!
> 
> There can be exceptions, but it's a dicey thing.  The UDC hardware would 
> have to be able to send handshake packets back to the host while 
> remaining in low power, it would have to be able to generate a wakeup 
> signal to bring its system back to full power, and the system would have 
> to be able to resume in time for the gadget to respond to a request from 
> the host before the request times out.
> 
> The situation is different if the gadget is already in USB suspend.  
> Then it only needs to be able to wake up its system when it gets a USB 
> resume signal.  But the system would still have to wake up reasonably 
> quickly.

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?

cheers,
-roger

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

[Alan Stern]

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.

Alan Stern

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

[Thinh Nguyen]

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
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.

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? 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?

Thanks,
Thinh

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

[Roger Quadros]

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

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

[Thinh Nguyen]

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?

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.

Thanks,
Thinh

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

[Alan Stern]

On Thu, Feb 16, 2023 at 06:11:36PM +0000, Thinh Nguyen wrote:
> On Thu, Feb 16, 2023, Roger Quadros wrote:
> > 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.

It's not specific to suspend/resume; it's a generic time limit.  It can 
vary depending on the application or the driver.

> 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.

Also, keep in mind that we can increase the initial timeout limit 
following a resume, if necessary (on Linux hosts with a recent kernel -- 
obviously not on other kinds of hosts).  Or make it an adjustable 
parameter.

> > > 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.

It the gadget is too slow in responding, it shouldn't be a big deal.  
The host will assume the gadget has disconnected and then will 
re-discover it.  Pretty much the same as if the gadget had actually 
disconnected from the bus before going into system suspend.

Alan Stern

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

[Roger Quadros]

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.

> 
> 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?

cheers,
-roger

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

[Thinh Nguyen]

On Thu, Feb 16, 2023, Alan Stern wrote:
> On Thu, Feb 16, 2023 at 06:11:36PM +0000, Thinh Nguyen wrote:
> > On Thu, Feb 16, 2023, Roger Quadros wrote:
> > > 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.
> 
> It's not specific to suspend/resume; it's a generic time limit.  It can 
> vary depending on the application or the driver.
> 
> > 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.
> 
> Also, keep in mind that we can increase the initial timeout limit 
> following a resume, if necessary (on Linux hosts with a recent kernel -- 
> obviously not on other kinds of hosts).  Or make it an adjustable 
> parameter.
> 
> > > > 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.
> 
> It the gadget is too slow in responding, it shouldn't be a big deal.  
> The host will assume the gadget has disconnected and then will 
> re-discover it.  Pretty much the same as if the gadget had actually 
> disconnected from the bus before going into system suspend.
> 

It may not be the same. The host may try to recover and reset the
device. If it fails after a few tries, it will stop communicate with the
device until the next port change event. So the worst possible case
would require the user to reconnect the device to trigger a port change
event for the host to respond and reconnect the device. I'm not sure how
easy it can get to that point. This requires some testings.

BR,
Thinh

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

[Thinh Nguyen]

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

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

[Roger Quadros]

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