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 10:41:40 -0500	[thread overview]
Message-ID: <Y+z9NK6AyhvTQMir@rowland.harvard.edu> (raw)
In-Reply-To: <7e28eb10-f27b-682a-dfb3-fec3e70b01f6@kernel.org>

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

  reply	other threads:[~2023-02-15 15:41 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 [this message]
2023-02-15 17:29   ` Roger Quadros
2023-02-15 18:24     ` Alan Stern
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+z9NK6AyhvTQMir@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