On Sun, 29 Sep 2013, Arokux X wrote: > > What happens if you back-port your glue driver to the vendor's kernel? > > I have now 200 lines of code which are (almost) identical. They work > in vendor's kernel and fail in mainline. This indicates that the problem isn't in your glue driver, but is somewhere else in the kernel. > > This isn't surprising. The errors you are getting are hardware errors, > > not protocol errors. They could be caused by excessive noise in the > > USB data lines. Or there could be some sort of timing issue. > > I've noticed there is ehci-timer.c now. It wasn't present at 3.4 > times. The main clock of the SoC I'm working on is running at 24Mhz. > There are no hstimers implemented. Do you think it can be the problem? I tend to doubt it. In the traces you posted, almost every transfer worked. Only a few of them got errors. If timers were a problem then none of the transfers would have worked. > A have tested several other USB devices: keyboard and Ethernet > adapter. They worked. I'm not sure whether these test are "clean" > since I connect them to the USB ports which are behind on-board 4-port > USB hub. The hub is connected to the first USB host controller. The > wifi module however is connected to the second USB host controller > directly. > > Do you have any ideas how can I troubleshoot this issue further? Is > there any chance of regression in EHCI stack? There's always a chance of a regression. Can you try connecting the WiFi module to a regular PC? Maybe that will provide some new ideas. In your traces, the working case had about 200 us between each URB completion and the following submission, whereas the non-working case had much less time -- around 20 us. Maybe in the new kernel, the bulk transfers occur too rapidly for the WiFi module to handle. Or maybe the problem lies in the EHCI hardware. Have you checked for errata? Alan Stern -- 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
