On Fri, 27 Sep 2013, Arokux X wrote: > I have done something simple, but reliable now. I have stripped the > vendors driver, so that it had only ~230 LOC. This driver was still > fully functional and wifi module worked. Then I carefully implanted it > into the mainline kernel, making only minimal changes to it. > Afterwards I tried to > > ip link set wlan0 up > > and saw exactly same errors in kernel log as with my driver (lots of > detected XactErr len 0/0 retry). This suggest the problem might be > elsewhere, for example in the wifi driver. To eliminate this unknown > I've used the wifi driver from 3.10 backports (not the latest > mainline) in the vendors tree (it is based on 3.4). The wifi module > still worked. So again - the problem is elsewhere. This time however I > do not know what to look for. I hope you can help. I don't know. Did you run all these tests on the same computer? What happens if you back-port your glue driver to the vendor's kernel? > The ARM SoC I am working on is Allwinner A10 aka sun4i. It belongs to > sunxi family. Not very much was mainlined so far. Some people have > suggested the missing DMA bits can be what causes the problem. I have > discovered the usb stack uses DMA too, since I assign dma_mask. The > vendors DMA driver that is used for my SoC is here [0]. > > Do you think the absence of the DMA support is what causing the > problem? Can I somehow check it? If not, what else could be? I doubt that DMA is the problem. If it were, the driver probably wouldn't work at all. > Additionally I have gathered logs with usbmon. The working.mon.out [1] > is from the legacy 3.4 vendor's kernel. The not-working.mon.out [2] is > the output I get with my driver. Maybe these logs can give some clue > too. I'm not familiar with the USB protocol used for WiFi, so I can't interpret the logs. As far as I can see, they are essentially the same. 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. > > The line where sunxi_ehci_init_module() assigns a string to > > sunxi_ehci_hc_driver.product_desc should be removed. > > I have found some discussion about this and now I understand why it > should be removed. Originally I was confused because OHCI overrides > allow you to specify product_desc. Now I assume it is a historical > leftover. Perhaps you want to unify this with EHCI drivers? If so, I > could submit a patch. Yes, ohci-hcd needs to be changed. I'll take care of it later on. > > What is the meaning of the "FIXME: Should there be two of those?" > > comment on line 215? Two of what? > > Two instances of the structure hc_driver. So rephrasing, is one > instance of the hc_driver enough to manage two EHCI controllers? One instance of hc_driver is enough to manage any number of controllers. It describes the driver, not the device -- one driver can work with any number of devices. > The new code with applied corrections can be found at [3], the whole > branch with dt bindings at [4]. Once the wifi problem is solved and > enough usb devices are tested I'll submit patches. > > Best regards, > Arokux > > [0] https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/plat-sunxi/dma.c > [1] https://www.dropbox.com/s/lpvp4jhsm4ki2tv/working.mon.out > [2] https://www.dropbox.com/s/hdu0dfdowofx737/not-working.mon.out > [3] https://github.com/arokux/linux/commit/c86e622367769173f8cf0e1af132d7ae9b3ee727 > [4] https://github.com/arokux/linux 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
