Hi all, I am implementing a driver (currently libusb-based, but may change to kernel-based eventually) for a USB standard class type that makes use of endpoint stalling as a synchronization mechanism to recover after error conditions between device and host (the reasons for needing it are a bit complex). The driver code I have been using works beautifully on Windows, some embedded OSes with proprietary USB stacks, and Linux via the EHCI driver. However, I ran into problems as soon as we started using this driver on XHCI systems (based off the 3.10 kernel). The sequence the driver typically does when encountering an error (or thinking it needs to resync) is: - Abort any pending URBs (may be several queued to the EP) - Set Feature(HALT) - Clear EP Stall - Continue What we saw with a bus analyzer was that, independent of host controller used (tested Intel and Renesas), the sequence number of the next outgoing packet (or toggle bit when in High Speed mode) was incorrect after clearing the stall. The device resets its expected sequence/toggle after un-stalling the EP and hence it ignores the next packet with the incorrect one. Interestingly, some devices are actually tolerant of this behavior and accept the incorrect sequence id, but any devices based on the Cypress FX3 (a large number of devices implementing this class type) fail. When researching this issue I saw a number of previous posts hinting at known issues like this, but I have not seen a firm conclusion. It seems that some of the early responses by Sarah Sharp indicate that it is working this way by design (I admit I am not an expert in the XHCI spec). I see some newer posts referencing a "clear halt bug", but I have been unable to find what this definitively is referencing. Based on my experience with how every other stack appears to work (including the Linux EHCI driver) and how the device is supposed to behave when it gets the clear stall request, I can't help but think that the behavior as it currently is is wrong. I can provide any additional information (bus traces, testing results, etc) as needed. If this is a known issue that someone can point me to the bugzilla entry for (I have been unsuccessful finding one) or some previous discussion threads I may have not found, it would be appreciated as well. Thanks, Eric Gross National Instruments -- 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
