linux-kernel - Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130524210503.GC15788@xanatos>
Date:	Fri, 24 May 2013 14:05:03 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Shawn Nematbakhsh <shawnn@...omium.org>,
	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-usb@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Julius Werner <jwerner@...omium.org>
Subject: Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky
 controllers.

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@...omium.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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/