USB device debugging

[mnarasimha786@gmail.com (Narasimha M)]

Thanks for clear explanation. Could you please let me know where does
host_controller will be present is it in USB device or USB core part
of kernel.

Actually my issue is that we ported Gobinet driver from open source to
support one dongle. After porting, it is working fine on little endian
host (linux-2.6.31 kernel). We have added some changes in driver code
o support it for big endian hosts. After adding the changes with the
help of le16_to_cpu () function dongle is working in one of our big
endian hosts (which has linux-3.10.20), but facing corrupted packet
issue in other bigendian supported host (linux-2.6.32). Could you
please help in providing some pointers here

On Wed, May 25, 2016 at 5:31 PM, Bj?rn Mork <bjorn@mork.no> wrote:
> Narasimha M <mnarasimha786@gmail.com> writes:
>
>> Thanks for the info. Sorry to ask you again, where does the usb driver
>> (GobiNet in my case) comes into picture in receive packet flow. I
>> suspect that the driver has to send some data (may be with some
>> interrupts) to rx_complete and then it will go to rx_submit. Is my
>> understanding is correct ? or if rx_submit is the first function to
>> generate the data, then where does Gobinet driver comes into place.
>> Could you please explain. I don't know how some usb driver works. This
>> is the first time i am working on it.
>
> GobiNet isn't part of the receive packet flow at all, if we assume a
> non-buggy Gobi device operating in 802.3 mode.  The rx_fixup callback is
> called, but it does nothing.  There isn't anything to do. The buffer is
> filled with an ethernet packet by the device + host controller.
>
> The usbnet_bh() tasklet is responsible for calling rx_submit (indirectly
> in newer kernels).  This is triggered by setting the EVENT_DEV_OPEN
> flag, which is done by usbnet_open().  GobiNet obfuscates this quite a
> bit, but it doen't do anything extra-ordinary here - it simply calls
> usbnet_open() when you open the netdev.
>
>
>
> Bj?rn



-- 
Narasimha