On Wed, 29 Dec 2010, Sarah Sharp wrote: > Hi Alan, > > I've been testing my split hub and USB 3.0 hub support patches, and I've > run into an interesting issue with the USB runtime PM support and > lsusub/libusb. > > The background is that device suspend has changed slightly for USB 3.0 > devices. Now that there are more "link states" (U0, U1, U2, and U3), > the way to suspend a device is through a new control transfer, not the > SetPortFeature PORT_SUSPEND. So of course, these changes will need to be integrated into the hub driver. > Remote wake has also changed for USB 3.0 devices. Instead of a "device" > waking up, there are "functions" on the device that wake up. The old > SetFeature DEVICE_REMOTE_WAKEUP isn't valid anymore, and instead the USB > core needs to set remote wakeup for each function on the device. Is this using the word "function" in a different sense from the USB-2.0 spec? In there, "function" means essentially the same thing as "non-hub USB device" means in the kernel. > The problem starts when I plug in a USB 3.0 hub into my system and the > USB core tries to suspend the device. First it tries to enable remote > wakeup. But it uses the old remote wakeup control transfer, which > causes the device to stall the endpoint. The core then says "won't > remote wakeup, status -32" and resumes the hub. > > I think that's valid fallback behavior, but there's something odd > happening with the USB runtime PM system when this happens. When I try > to use `lsusb -v` for the device (either with the -s or -d option), > lsusb prints "Couldn't open device, some information will be missing" > (even with sudo to fix any permission problems). Then it falls back to > only printing some of the device descriptors, and stops when it prints > bNumConfigurations. It exits fine if I run it as sudo, but if I run it > as a normal user, it segfaults after printing the descriptor, and then > starts to hang after printing on subsequent runs. Luckily, it's > killable, and the hub works normally except for device suspend, but it's > disturbing behavior. > > I've tracked down the issue with the "Couldn't open device" message into > the USB core. After the failed suspend, usbdev_open() returns -EINVAL > for the USB 3.0 hub. I've added some debugging to the usbfs driver > (patch attached), and it looks like usb_autoresume_device() is returning > the error code. The only interesting call in there is to > pm_runtime_get_sync(). > > Could there be something wrong with the USB core PM runtime code? It > seems like if a device fails to suspend and is resumed, > usb_autoresume_device() ought to succeed... Yes, there's a bug. usb_runtime_suspend() returns the status value it receives from usb_suspend_both(). However the PM core reacts badly unless the return code is 0, -EAGAIN, or -EBUSY. If usb_suspend_both() returns anything other than 0, usb_runtime_suspend() should set status to -EBUSY before returning it. Alan Stern -- 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
