I've been testing the new USB 3.0 Link PM (LPM) code with more devices, and I'm starting to wonder if the kernel needs to be a bit smarter about when it enables LPM. The USB 3.0 spec mandates that all device support link PM, but some don't of course. There's interesting states of brokenness, and I'd like to get your opinions about how to deal with them. Some devices just don't want to go into a lower power link state. There's a way for devices to NAK a request to transition to a lower power link state, and these devices always NAK the request. That's fine, since transmitting a bunch of LGO_U1/LAUX link commands doesn't cost any more power than transmitting logical idles from the PHY perspective. Some of those devices try to signal they don't support link PM by using the U1/U2 device exit latencies in the SuperSpeed BOS descriptor. Valid values are 0 (no exit latency) to 10us (for U1) or 2047us (for U2). Devices that always NAK the request to go into a lower power link state often have their exit latencies set to the max values (10us and 2047us). However, other devices break when asked to go into U1 or U2. Don's Western Digital hard drive is an example of that. His device sets the U1/U2 device exit latencies to zero. So, my initial fix to work around broken devices was to not enable LPM for devices with the minimum or the maximum exit latencies. However, now I've found this lovely broken SIIG hub with a VIA chipset that I'm coming to hate. This hub sets the U1 timeout to 10 (the max) and the U2 timeout to 231 (not the max). When asked to go into U1 or U2, I can see from the bus trace that it does. And then it starts sending U3 wakeup signaling. This is obviously broken at the hardware level. There is a firmware update for the hub: http://www.siig.com/download/search/?keyword=JU-H70112-S1 However, I'm not sure if it's reasonable to expect that the average Linux user be able to update their hub's firmware. SIIG expects you to create a bootable DOS disk and run their executable *under a Renesas host*. I haven't tried under an Intel xHCI host, because I've been wanting to keep the broken behavior around. One way we could work around these broken devices is have a dynamic black list of device vendor and product IDs that shouldn't have LPM enabled. We already have such a black list in the xHCI driver for devices that don't handle USB 2.0 LPM. My idea is to add the device to the black list if USB core control transfers start timing out, or any URBs complete with transfer errors. That way when the device reconnects (as the SIIG hub does), we won't enable LPM again. The SIIG hub stops responding to the second control transfer needed to enable LPM (Set Feature Device initiated LPM), so we catch the failure pretty early on in the enumeration process. The other option is to just create a sysfs file for USB 3.0 link PM, turn it off by default, and leave it up to userspace. But that means basically no one will have it enabled. So I'd like to pursue a dynamic option in the kernel. Thoughts? 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
