Linux USB
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Roger Quadros <rogerq@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: dwc3: gadget suspend/resume vs system suspend/resume
Date: Wed, 15 Feb 2023 13:24:37 -0500	[thread overview]
Message-ID: <Y+0jZScRX80mF8tS@rowland.harvard.edu> (raw)
In-Reply-To: <3b530a74-0fb9-432b-b1d9-606a9694ce1e@kernel.org>

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

  reply	other threads:[~2023-02-15 18:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-15  9:40 dwc3: gadget suspend/resume vs system suspend/resume Roger Quadros
2023-02-15 15:41 ` Alan Stern
2023-02-15 17:29   ` Roger Quadros
2023-02-15 18:24     ` Alan Stern [this message]
2023-02-15 22:53       ` Thinh Nguyen
2023-02-16  8:40         ` Roger Quadros
2023-02-16 18:11           ` Thinh Nguyen
2023-02-16 20:03             ` Alan Stern
2023-02-16 22:10               ` Thinh Nguyen
2023-02-16 20:43             ` Roger Quadros
2023-02-16 22:23               ` Thinh Nguyen
2023-02-17  9:28                 ` Roger Quadros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+0jZScRX80mF8tS@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=rogerq@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox