On Mon, Oct 7, 2013 at 12:41 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. Ok, my mistake, that should read "xhci attached non-SuperSpeed USB devices", which is what the code does. > >> 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). Yes, copy paste error when I added the BSR annotations, had it right in v1 > >> ...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. Follows that this should be "non-SuperSpeed devices" as well. >> >> 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 SuperSpeed. >> 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? Yes, 18. > >> 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). Thanks for that. -- Dan -- 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
