Re: EHCI bus glue driver works for storage, fails for a WiFi module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Alan,

thank you very much for your reply. It was very encouraging. I am
totally new to kernel development and it took me quite some time to
gather all the bits needed for this simple glue driver.

On Tue, Sep 24, 2013 at 5:22 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> 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.

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.

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?

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.

>> 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().

Yes, thank you.

> 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.

> 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?

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
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux