On Mon, 7 Oct 2013, Dan Williams wrote: > Change the default enumeration scheme for xhci attached USB < 3 devices > from: Careful about the distinction between USB-3 and SuperSpeed. They aren't synonymous. > Reset > SetAddress [xhci address-device BSR = 0] > GetDescriptor(8) > GetDescriptor(18) > > ...to: > > Reset > [xhci address-device BSR = 1] > GetDescriptor(64) > Reset > SetAddress [xhci address-device BSR = 0] > GetDescriptor(8) > GetDescriptor(18) This description isn't right. The "new" scheme skips the Get-Descriptor(8) step entirely. It goes directly from the second reset to Get-Descriptor(18). > ...as some devices misbehave when encountering a SetAddress command > prior to GetDescriptor. There are known legacy devices that require > this scheme, but testing has found at least one USB3 device that fails > enumeration when presented with this ordering. For now, follow the ehci > case and enable 'new scheme' by default for USB < 3 devices. > > To support this enumeration scheme on xhci the AddressDevice operation > needs to be performed twice. The first instance of the command enables > the HC's device and slot context info for the device, but omits sending > the device a SetAddress command (BSR == block set address request). > Then, after GetDescriptor completes, follow up with the full > AddressDevice+SetAddress operation. > > As mentioned before, this ordering of events with USB3 devices causes an > extra state transition to be exposed to xhci. Previously USB3 devices > would transition directly from 'enabled' to 'addressed' and never need > to underrun responses to 'get descriptor'. We do see the 64-byte > descriptor fetch the correct data, but the following 8-byte descriptor > read after the reset gets: Are you sure you don't mean 18-byte instead of 8-byte? > bLength = 0 > bDescriptorType = 0 > bcdUSB = 0 > bDeviceClass = 0 > bDeviceSubClass = 0 > bDeviceProtocol = 0 > bMaxPacketSize0 = 9 > > instead of: > > bLength = 12 > bDescriptorType = 1 > bcdUSB = 300 > bDeviceClass = 0 > bDeviceSubClass = 0 > bDeviceProtocol = 0 > bMaxPacketSize0 = 9 > > which results in the discovery process looping until falling back to > 'old scheme' enumeration. In any case, I agree that sticking with the "old" scheme for SuperSpeed devices is a good idea, because that's most likely to be what other OS's use (since it is what the hardware supports most directly). 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