On Fri, Oct 05, 2012 at 04:51:53PM -0400, Alan Stern wrote: > On Fri, 5 Oct 2012, Sarah Sharp wrote: > > > 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. > > We could add a USB_QUIRK_NO_LPM flag and put a static entry for the > SIIG hub (and maybe other broken devices) in quirks.c. xhci-hcd could > set this flag when it sees control transfers timing out or other > transfer errors. I think it would make sense to use the static entry for the SIIG hub, since the other VIA hubs I have also exhibit this hardware issue, and they all have the same VID:PID. The flag you're talking about is a bit in usb_device->quirks, right? That would only apply to the particular USB device that's acting up, so when that device disconnected, the quirks information effectively goes away, correct? On a replug, the host will see at least one more transfer error before the flag is re-applied, which isn't great for hard drives. Would it make sense to load the usb_quirks_list into a linked list at USB core initialization time, and then allow drivers to dynamically add entries to it? 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
