Hi All, While reviewing and testing patches for my latest uas patch series, I realized that uas did not have suspend / resume support. Which is not good for a storage driver, since that means a disconnect and reconnect will happen over suspend resume, causing any mounted filesystems on the disk to be unusable until re-mounted. Implementing suspend / resume was not that hard, testing it is another story. I ended up testing USB-3 superspeed device suspend / resume support in general. Below is a report with my findings. I've tested using 4 (*) host configurations: 1.1) My desktop machine with a pci-e add-on card with a nec xhci controller. The firmware completely turns of the power to the pci-e card, triggering the xhci reset-resume paths. With devices plugged directly a root-hub port. 1.2) Same desktop machine with devices plugged into a build-in via vl811 usb-3 hub. Note the hub also looses all power during suspend/resume. 2.1) My dell latitude e6430 laptop, with intel series 7 chipset (pantherpoint) build-in xhci controller, with devices plugged into its regular usb-3 port The xhci controller stays powered during suspend / resume, so the xhci suspend / resume code uses the regular resume path. but the port gets Vbus turned off during suspend, and restored on resume causing attached devices to enter the reset-resume path. 2.2) Same laptop, with devices plugged into the "power-sharing" usb-3 port, which gets Vbus turned off for a second, then turned back again during suspend. And it gets worse, after resume, while the kernel is already running and is resuming devices, the embedded controller controlling the ports toggles the power off for about .5 seconds and back on again. This Vbus toggle may happen before or after the kernel has resumed the device. If it happens after the kernel has resumed the device, but before khubd gets to run, khubd may not see the disconnect / re-connect, even though the device has lost state! I've tested with 3 devices: 1) usb-2 stick: Brandless, the ones with the flasing lights handed out at plumbers in portland 2) usb-3 stick: Corsair Flash Voyager 16 GB 3) usb-3 uas capable sata dock: Plugable USB3-SATA-UASP1 in uas mode (**) And the results: nec xhci + usb-2 stick on root hub port: reset-resume of xhci + stick: success nec xhci + usb-2 stick on vl811 hub port: reset-resume of xhci + hub + stick: success intel xhci + usb-2 stick on regular usb-3 port: resume of xhci + reset-resume of stick: success intel xhci + usb-2 stick on power-sharing usb-3 port: resume of xhci success stick gets seen as disconnected and the stick needs to be unplugged and replugged for it to be seen again nec xhci + usb-3 stick on root hub port: reset-resume of xhci + stick: success nec xhci + usb-3 stick on vl811 hub port: reset-resume of xhci + hub + stick: success intel xhci + usb-3 stick on regular usb-3 port: resume of xhci: success stick seen as disconnected, shows up again without intervention after circa 1 second intel xhci + usb-3 stick on power-sharing usb-3 port: resume of xhci: success stick seen as disconnected, shows up again without intervention after circa 2 seconds nec xhci + uas dev on root hub port: reset-resume of xhci: success uas dev seen as disconnected, shows up again without intervention after several seconds nec xhci + uas dev on vl811 hub port: reset-resume of xhci + hub: success uas dev seen as disconnected, shows up again without intervention after several seconds intel xhci + uas dev on regular usb-3 port: resume of xhci and reset-resume of uas: success intel xhci + uas dev on power-sharing usb-3 port: resume of xhci: success device seen as disconnected, shows up again without intervention after circa 2 seconds Conclusions: 1) The power-sharing port on the Dell E6430 is a typical example of how broken firmware can be, due to its Vbus toggling after resume it fails to properly suspend / resume any devices. If users care about usb device persistence over suspend / resume for devices plugged into that port they should disable the power sharing feature in the BIOS (which will disable the broken Vbus toggling) 2) Where as USB-2 device don't seem to care much about Vbus being turned on/off during resume, USB-3 (operating at USB-3 speeds) devices do care about this, and depending on (root)-hub and device combination they may or may not suffer a disconnect / reconnect over suspend / resume. I've tried various things to make the disconnect / reconnect go away, but nothing short of inserting unacceptable long sleeps seems to help :| It seems we will need to educate BIOS authors that USB-3 has excellent powermanagement in the spec and that USB-3 ports should not be powered off during suspend. Regards, Hans p.s. I've also ran some tests with the uas device on the intel xhci with the XHCI_RESET_ON_RESUME quirk set to test that code path with streams, and I promptly found a bug there. I've a patch fixing this which will be part of my next uas/xhci patch-set. *) I've also ran some tests with a via vl812 usb-3 hub, but those did not yield any interesting results compared to to vl811 tests **) I've also ran a few (but not all) test in usb-storage mode, this does not seem to make a difference -- 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
