On Mon, 23 Sep 2013, Arokux X wrote: > Hi, > > recently I was working on porting EHCI HCD bus glue driver from the > vendors kernel tree to the mainline [1]. I've got the storage (USB > stick and USB external hard drive) working and was happy. However it > does not work completely. Specifically something goes wrong if WiFi > module is talked to. This WiFi module is on-board and connected > through USB. The WiFi module is correctly identified and the rtl8192cu > driver manages to output something, but issuing > > ip link set wlan0 up > > will cause an error, see the output of the dmesg [2]. > > Note, the same hardware works with vendor's tree EHCI bus glue driver > and rtl8192cu, so hardware is ok. > > Maybe using a fact that my driver works for the storage but fails for > the WiFi module you could help me identify the problem in it? Nope. Not without comparing it to the vendor's driver. > By the way, the output of the lsusb -vvvv looks identical in both > cases (with my driver and vendor's) [3]. One problem is the part of the patch that changes ehci-hcd.c. That hunk should be removed (it caused the "Error: Driver 'sunxi-ehci' is already registered, aborting..." message at timestamp 0.781332 in your log). If usb_add_hcd() fails, you don't call sunxi_ehci_disable(). There's another problem in sunxi_ehci_remove(). The routine accesses sunxi_ehci after it has been deallocated by the call to usb_put_hcd(). The line where sunxi_ehci_init_module() assigns a string to sunxi_ehci_hc_driver.product_desc should be removed. What is the meaning of the "FIXME: Should there be two of those?" comment on line 215? Two of what? Why does the sunxi_ehci_hcd structure contain an "hcd" member? This member is used in only one function, and you could easily pass it as a function argument instead. 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
