Hello linux-usb! I am the administrator of SANE (Scanner Access Now Easy), which provides scanner drivers for over 1000 models of scanner on multiple platforms, including Linux. Many of those scanners are USB, and we have had an increase in bug reports in some of those as of late. So, I have done some initial investigation, and need some help. Generally, we use a wrapper around libusb for our access, and don't have to worry much about kernel-level details. However, we have a number of reports where our code works perfectly when a scanner is attached to a usb port controlled by ehci_hcd, but fails when that same port is controlled by xhci_hcd. The libusb, sane, and kernel versions are varied, though the behaviour is consistent. This seems at first glance to be a Data0/1 toggle problem. Specifically, the sane protocol has a detection step, followed by a separate 'actually do something' step. The former involves many distinct drivers each trying in turn to open, communicate with, and close any attached scanners they recognise. The latter is a single driver reopening a single scanner, and doing more extensive communications before closing again. Under USB 2, this pattern works, though the second step sometimes requires retries on the first command sent, because the Data toggle is confused. Attempts to use that same code on USB 3 (including the retries) fail. Modifications to the initial step to either: 1. stop closing the descriptor, or 2. make the number of commands even, seem to correct the problem for at least one iteration of the process. So, my questions- What is different about the handling of the Data toggle between the implementation of USB 2 and 3, and is there something different that we should be doing from user space to prevent this issue? I will be happy to provide additional debugging info, just let me know. Thanks for any insights- allan -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand" -- 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
