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. > > 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. > > 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? Sarah Sharp -- 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
