From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Shawn Nematbakhsh <shawnn@chromium.org>,
Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
Julius Werner <jwerner@chromium.org>
Subject: Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers.
Date: Fri, 24 May 2013 14:05:03 -0700 [thread overview]
Message-ID: <20130524210503.GC15788@xanatos> (raw)
In-Reply-To: <1369419177-23281-1-git-send-email-shawnn@chromium.org>
On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
> If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
> a reset will be performed upon runtime resume. Any previously suspended
> devices attached to the controller will be re-enumerated at this time.
> This will cause problems, for example, if an open system call on the
> device triggered the resume (the open call will fail).
That's ugly, but disabling runtime PM is going to have a big impact on
the power consumption of those systems.
Alan, do you think this is really the right thing to be doing here? It
feels like userspace should just be able to deal with devices
disconnecting on resume. After all, there are lots of USB devices that
can't handle USB device suspend at all.
Shouldn't userspace just disable runtime PM for the USB device classes
that don't have a reset resume callback?
> Note that this change is only relevant when persist_enabled is not set
> for USB devices.
Could we at least wrap the call in an ifdef CONFIG_USB_DEFAULT_PERSIST?
That way if people have USB persist turned off in their configuration,
their host will still be able to suspend.
Sarah Sharp
>
> Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
> ---
> drivers/usb/host/xhci.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index b4aa79d..7455156 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4687,6 +4687,12 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
>
> get_quirks(dev, xhci);
>
> + /* If we are resetting upon resume, we must disable runtime PM.
> + * Otherwise, an open() syscall to a device on our runtime suspended
> + * controller will trigger controller reset and device re-enumeration */
> + if (xhci->quirks & XHCI_RESET_ON_RESUME)
> + pm_runtime_get_noresume(dev);
> +
> /* Make sure the HC is halted. */
> retval = xhci_halt(xhci);
> if (retval)
> --
> 1.7.12.4
>
next prev parent reply other threads:[~2013-05-24 21:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 18:12 [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers Shawn Nematbakhsh
2013-05-24 21:05 ` Sarah Sharp [this message]
2013-05-25 14:11 ` Alan Stern
2013-05-25 16:59 ` Shawn Nematbakhsh
[not found] ` <CALaWCOOGEDtF1z29df2ST9kV-VpMa9VbvFK0Hh71WJG5f_pngA@mail.gmail.com>
2013-05-28 20:58 ` Sarah Sharp
2013-05-28 21:41 ` Julius Werner
2013-05-29 14:23 ` Alan Stern
2013-05-29 19:38 ` Sarah Sharp
2013-05-29 20:11 ` Alan Stern
2013-05-29 20:32 ` Don Zickus
2013-06-03 11:33 ` Oliver Neukum
2013-08-09 17:22 ` Sarah Sharp
2013-08-12 15:49 ` Shawn Nematbakhsh
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=20130524210503.GC15788@xanatos \
--to=sarah.a.sharp@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shawnn@chromium.org \
--cc=stern@rowland.harvard.edu \
/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