On 04.11.2014 23:58, m. allan noah wrote: > 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 > Hi I was looking at some time ago. If I remember correctly the issue was believed to be that xhci refuses to reset an endpoint if it's not halted. SetFeature(ENDPOINT_HALT) will set the device to halted state, but it requires some additional transfer that returns STALL until xHCI will see the endpoint as halted. Same goes for calling reset endpoint as a "soft reset" on xhci, expecting toggle to reset will not work unless the endpoint is actually halted. There was an addition to xhci specs about this, with a solution proposal: " If software wishes reset the Data Toggle or Sequence Number of an endpoint that isn't in the Halted state, then software may issue a Configure Endpoint Command with the Drop and Add bits set for the target endpoint." I got some code for handling this, so far I got very mixed results (fixes, doesn't fix, new minor issues, or new major issus seen). You can try it out at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test https://git.kernel.org/cgit/linux/kernel/git/mnyman/xhci.git/log/?h=ep_reset_halt_test (remember to checkout the ep_reset_halt_test branch) But it's some time since I wrote it, and I since then got a bit better understanding about the xhci reset handling. I need to revisit it again. -Mathias -- 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
