On Fri, Mar 05, 2010 at 08:16:00PM -0800, Ramesh.R wrote: > Hi Sarah, > > We are testing our USB3.0 device against xHCI v.96 based USB3.0 Host board. > During our test, we observed an erroneous behaviour from the xHCI stack. > > Here is the sequence: > 1. Device settles in SuperSpeed. > 2. Device completed successful link training sequence. > 3. Device completes successful SetAddress command. (New address 2 is > assigned) > 4. The stack initiates GetDescriptor, and the device does not respond to the > GetDescriptor command.(intentional) Why do you not respond to the GetDescriptor command? This is a perfectly valid sequence of events, it's just different than what Windows does. > 5. The software stack initiates the SetAddress command for address 0. > > Since, the sequence #3 has forced the device to an address state, the > sequence #5 is not completed. The USB 3.0 spec says (in section 9.4.6) that when a device is in the addressed state, and it receives a SetAddress and "If the address specified is zero, then the device shall enter the Default state." Why would you not complete the fifth step? > We believe a warm-reset or Hot-reset before the sequence #5 would solve the > problem. The Linux USB enumeration sequence has worked fine for many different USB devices, including many USB 3.0 devices. I would like to keep it the same in order not to break devices that are already out on the market. Can you fix this in hardware? > Can you please suggest how to fix this issue in software, or can you suggest > an alternative solution. Which kernel version are you running? The support to reset devices under xHCI was only merged into Linus' patchset for 2.6.33 recently. Are you running a kernel compiled from my git tree? 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
