On 10/07/2014 06:07 PM, Alan Stern wrote:
> On Mon, 6 Oct 2014, Dmitry Nezhevenko wrote:
>
>>> What does the debugging log show if you don't disable wakeup?
>>
>> $It looks like same, but later it resumes once again.
>>
>> [ 2836.134277] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
>> [ 2836.134340] hub 2-0:1.0: hub_suspend
>> [ 2836.134346] usb usb2: bus auto-suspend, wakeup 1
>> [ 2838.797692] usb 1-12: usb auto-suspend, wakeup 0
>> [ 2839.237510] usb 1-5: usb auto-suspend, wakeup 0
>> [ 2839.405473] usb 1-7: usb auto-suspend, wakeup 0
>> [ 2839.421487] hub 1-0:1.0: hub_suspend
>> [ 2839.421497] usb usb1: bus auto-suspend, wakeup 1
>> [ 2839.421586] xhci_hcd 0000:00:14.0: hcd_pci_runtime_suspend: 0
>> [ 2839.421622] xhci_hcd 0000:00:14.0: PME# enabled
>> [ 2839.453479] xhci_hcd 0000:00:14.0: power state changed by ACPI to D3cold
>> [ 2854.647991] xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
>> [ 2854.751914] xhci_hcd 0000:00:14.0: PME# disabled
>> [ 2854.751928] xhci_hcd 0000:00:14.0: enabling bus mastering
>> [ 2854.751989] xhci_hcd 0000:00:14.0: hcd_pci_runtime_resume: 0
>> [ 2854.751994] xhci_hcd 0000:00:14.0: hcd_pci_runtime_suspend: -16
>> [ 2854.752017] pci_pm_runtime_suspend(): hcd_pci_runtime_suspend+0x0/0x40 [usbcore] returns -16
>> [ 2854.752019] usb usb1: usb wakeup-resume
>> [ 2854.752026] usb usb1: usb auto-resume
>> [ 2854.752056] hub 1-0:1.0: hub_resume
>> [ 2854.752095] usb usb1-port5: status 0107 change 0000
>> [ 2854.752107] usb usb1-port7: status 0107 change 0000
>> [ 2854.752125] usb usb1-port12: status 0507 change 0000
>> [ 2854.855937] hub 1-0:1.0: state 7 ports 15 chg 0000 evt 0000
>> [ 2854.855951] hub 1-0:1.0: hub_suspend
>> [ 2854.855966] usb usb1: bus auto-suspend, wakeup 1
>> [ 2854.856002] usb usb1: suspend raced with wakeup event
>
> That's the difference. It appears to be caused by a bug in xhci-hcd.
> Does the patch below fix the problem?
>
> Alan Stern
>
>
>
> Index: usb-3.17/drivers/usb/host/xhci-hub.c
> ===================================================================
> --- usb-3.17.orig/drivers/usb/host/xhci-hub.c
> +++ usb-3.17/drivers/usb/host/xhci-hub.c
> @@ -1136,13 +1136,11 @@ int xhci_bus_suspend(struct usb_hcd *hcd
> t2 |= PORT_LINK_STROBE | XDEV_U3;
> set_bit(port_index, &bus_state->bus_suspended);
> }
> - /* USB core sets remote wake mask for USB 3.0 hubs,
> - * including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
> - * is enabled, so also enable remote wake here.
> + /* USB core sets remote wake mask for USB 3.0 hubs but
> + * not for USB 2.0 hubs (and only if CONFIG_PM_RUNTIME
> + * is enabled), so enable remote wake here.
> */
> - if (hcd->self.root_hub->do_remote_wakeup
> - && device_may_wakeup(hcd->self.controller)) {
> -
> + if (hcd->self.root_hub->do_remote_wakeup) {
> if (t1 & PORT_CONNECT) {
> t2 |= PORT_WKOC_E | PORT_WKDISC_E;
> t2 &= ~PORT_WKCONN_E;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi
The device_may_wakeup() check was recently added in patch:
commit ff8cbf250b448aac35589f6075082c3fcad8a8fe
xhci: clear root port wake on bits if controller isn't wake-up capable
http://marc.info/?l=linux-usb&m=140261803101225&w=2
Seems it caused some unexpected issues.
Is there some way to fix both cases before ending up reverting that patch?
Any idea why hcd_bus_suspend() doesn't see the suspend race when calling hcd->driver->hub_status_data() in any case?
Are the wake-on [dis]connect bits somehow tied to connect status change bits?
When hcd_bus_suspend() checks for the suspend race condition it checks all xhci status change bits.
Shouldn't those indicate a connect change and prevent the second suspend?
Or maybe we should check for those bits resume as well?
Baolu, do you still have the hardware that caused spurious wakeups? do we know in detail what caused the wakeup?
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
