On Wed, 11 Jan 2012, Sarah Sharp wrote: > Sigh. So it turns out the behavior of USB 3.0 external hubs and the > xHCI roothub port link state change bit is different. > > The USB 3.0 bus spec, section 10.14.2.6.2 says the port link state > change bit will be set when the port goes from U3 to U0 when the host > initiated the resume, but the bit will *not* be set if the device has > signaled remote wakeup. But the xHCI spec says that the link state > change bit will be set on a remote wakeup. The spec is a little confusing. 9.2.5.2 talks about a Function Wake Notification and refers to section 7.4.9, which doesn't exist. Maybe it means 8.5.6.4. > I think the idea is that software is supposed to know to resume a device > by looking at the device notification the device sends (and the xHCI > host passes on in an event) when the roothub port finishes resuming. > Only the xHCI host doesn't send device notifications itself, so it uses > the link state change. What does xhci-hcd do with the device notifications? > The xHCI driver needs a way to tell khubd which device caused the remote > wakeup, because khubd won't be able to tell by looking at the link state > change bits. It could possibly tell, if it internally kept track of > which link state each USB 3.0 device should be in, and checked which > ports changed link states to U0. > > I'll go look at the hub code more closely to see what it currently does, > but I thought I'd pass my finding on to you and see if you have any > thoughts. For SuperSpeed hubs, the wakeup code will probably have to look at the link state status bits instead of the link state change bits. I guess we could do the same thing with non-SuperSpeed hubs -- look for ports whose suspend status bit isn't set but where the child device is marked as being in USB_STATE_SUSPENDED. 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
