On Wed, Jan 26, 2011 at 12:29:18PM -0800, Alan Stern wrote: > On Wed, 26 Jan 2011, Micah Elizabeth Scott wrote: > > > On Wed, Jan 26, 2011 at 12:06:06PM -0800, Alan Stern wrote: > > > > > The alternative is to reject low- and full-speed devices when they are > > > plugged into a high-speed hub with no TTs. How does this look? > > > > I'm not really qualified to sign off on the patch itself, since I > > don't know what expectations the rest of the USB code has about tt and > > tt->hub. But I'd be fine with this solution in concept at least. > > Can you try it out and verify that it fixes the problem with your buggy > hub? Our lead USB QA engineer tested out your patch, and it looks good! We reproduced the problem using a buggy version of our hub device, and with your patch the buggy hub's child device is correctly rejected: [ 13.753061] usb 1-4.7: new full speed USB device using xhci_hcd and address 10 [ 13.753067] usb 1-4.7: parent hub has no TT [ 13.824921] usb 1-4.7: new full speed USB device using xhci_hcd and address 11 [ 13.824926] usb 1-4.7: parent hub has no TT [ 13.896774] usb 1-4.7: new full speed USB device using xhci_hcd and address 12 [ 13.896779] usb 1-4.7: parent hub has no TT [ 13.968632] usb 1-4.7: new full speed USB device using xhci_hcd and address 13 [ 13.968637] usb 1-4.7: parent hub has no TT [ 13.969029] hub 1-4:1.0: unable to enumerate USB device on port 7 Tested-by: Perry Neben <neben@xxxxxxxxxx> Thanks! --beth -- 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
