On Wed, 29 Dec 2010, Sarah Sharp wrote: > On Wed, Dec 29, 2010 at 11:59:13PM -0500, Alan Stern wrote: > > 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. > > Yes. I suspect that may not happen for the next merge window, but I am > hoping to get the basic USB 3.0 hub support in. In the meantime you could disable autosuspend for USB-3 hubs: add a check before the usb_enable_autosuspend() call in hub_probe(). > > > 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. > > This is a different meaning. A non-hub device is defined by the USB 3.0 > spec as a "peripheral device" and a hub is, well, a hub device. A > function in the USB 3.0 sense is a set of related interfaces on one > device, described by an interface association descriptor (IAD). All USB > 3.0 devices must have at least one IAD and one function. > > Say you could have a USB 3.0 device with a webcam and speaker. There > might be two IADs, with one describing the video interfaces that fall > into one function, and another IAD that describes the audio interfaces > as another function. Then when you're recording video but you're not > using the speakers, you could suspend the audio function. Originally we decided that the USB core would support suspending entire devices, not individual interfaces. Looks like we may have to rethink that policy. Still, is there any simple way to put the entire device, including all its functions, into a low-power suspend state? > > > 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. > > Ok, what about in usb_runtime_resume()? Does the status need to get > overwritten there? No. Any nonzero value is essentially an unrecoverable error. Right now we don't have any cleanup code for such things; it's not clear what that code would want to do. 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
