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: <Pine.LNX.4.44L0.1608101026080.1843-100000@iolanthe.rowland.org>
Date:	Wed, 10 Aug 2016 10:31:10 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Baolin Wang <baolin.wang@...aro.org>
cc:	gregkh@...uxfoundation.org, <stefan.koch10@...il.com>,
	<oneukum@...e.com>, <falakreyaz@...il.com>, <broonie@...nel.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] usb: core: Add runtime resume checking in choose_wakeup()

On Wed, 10 Aug 2016, Baolin Wang wrote:

> Considering strict power management for mobile device, we should also power
> off the usb controller if there are no slaves attached even though it is usb
> host function, but it will meet usb device resume failure in below situation.
> 
> Suppose that no slave attached ----> usb interface runtime suspend ---->
> usb device runtime suspend -----> xhci suspend -----> power off usb controller.
> After that if the system wants to enter suspend state, then it also will issue
> usb_dev_suspend(), then the pm_runtime_resume() issued in choose_wakeup()
> function will return '-ESHUTDOWN' due to xhci has been suspend and hardware is
> not accessible.

No, this is wrong.  The pm_runtime_resume in choose_wakeup() should 
cause the xHCI controller to resume also.

> After system entering resume state, if there is slave attached ----> power on
> usb controller ----> xhci resume ----> usb device runtime resume ---->
> usb interface runtime resume. But usb device will resume failed if runtime
> errors is set ('-ESHUTDOWN'), thus we should clear the runtime errors in
> choose_wakeup() function to avoid this situation.

If the controller resumes correctly, this won't be necessary.

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ