[U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC

[Stephen Warren <swarren@wwwdotorg.org>]

On 06/27/2014 03:52 PM, J?rg Krause wrote:
> I have tested a little bit more.
> 
> It does NOT help waiting some seconds before running tftp again.
> Sometimes it just works running tfpd immediately after a previous tfpd.
> Sometimes waiting even a minute ends up in the described error.
> 
> Odd, very odd, sorry :-)

OK, that makes a little more sense. Intermittent issues are fine, but
intermittent issues affected by time delays are odd!

Does the *first* invocation of "tftp" after the board is powered on
always work perfectly?

> On 06/27/2014 11:37 PM, J?rg Krause wrote:
>> I added the last series of patches beginning from 2014-06-10 for
>> testing purposes. The patches from 2014-05-29 were already applied.
>>
>> First series of patches:
>>
>>    Applying: usb: ci_udc: call udc_disconnect() from ci_pullup()
>>    Applying: usb: ci_udc: fix freeing of ep0 req
>>    Applying: usb: ci_udc: fix probe error cleanup
>>    Applying: usb: ci_udc: clean up all allocations in unregister
>>
>> Calling tftp the first time after a reset runs fine, but calling it a
>> second time ends always in a crash. I have to reset the device.
>>
>> Next patch:
>>
>>    Applying: usb: ci_udc: terminate ep0 INs with a zlp when required
>>
>> Did not help.
>>
>> Next patch:
>>
>>    Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
>>
>> This helps! U-Boot does not crash anymore. But there is still a
>> problem: I have to wait some seconds before I can run a second time
>> tftp. This is the output from U-Boot:
>>
>>    => run update_rootfs
>>    Updating rootfs ...
>>    using ci_udc, OUT ep- IN ep- STATUS ep-
>>    high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
>>    USB network up!
>>    Using usb_ether device
>>    [snip]
>>
>>    => run update_rootfs
>>    Updating rootfs ...
>>    using ci_udc, OUT ep- IN ep- STATUS ep-
>>    high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
>>    ERROR: The remote end did not respond in time.
>>    at drivers/usb/gadget/ether.c:2388/usb_eth_init()
>>
>> Wait some seconds ...
>>
>>    => run update_rootfs
>>    Updating rootfs ...
>>    using ci_udc, OUT ep- IN ep- STATUS ep-
>>    high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
>>    USB network up!
>>    Using usb_ether device
>>    [snip]
>>
>> Best regards
>> J?rg Krause
>>
>> On 06/25/2014 06:06 PM, Stephen Warren wrote:
>>> On 06/25/2014 07:51 AM, Marek Vasut wrote:
>>>> On Monday, June 23, 2014 at 08:02:48 PM, Stephen Warren wrote:
>>>>
>>>> +CC Jorg, rest of email is intact. Jorg, does this patch fix your
>>>> issue?
>>> Jorg's issue was timeouts during transfers, whereas this patch addresses
>>> cleanup issues once the device isn't being used any more. I can't
>>> imagine how this patch could influence the issue Jorg is seeing.
>>>
>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>
>>>>> ci_udc.c's usb_gadget_unregister_driver() doesn't call
>>>>> driver->unbind()
>>>>> unlike other USB gadget drivers. Fix it to do this.
>>>>>
>>>>> Without this, when ether.c's CDC Ethernet device is torn down,
>>>>> eth_unbind() is never called, so dev->gadget is never set to NULL.
>>>>> For some reason, usb_eth_halt() is called both at the end of the first
>>>>> use of the Ethernet device, and prior to any subsequent use. Since
>>>>> dev->gadget is never cleared, all calls to usb_eth_halt() attempt to
>>>>> stop, disconnect, and clean up the device, resulting in double
>>>>> cleanup,
>>>>> which hangs U-Boot on my Tegra device at least.
>>>>>
>>>>> ci_udc allocates its own singleton EP0 request object, and cleans
>>>>> it up
>>>>> during usb_gadget_unregister_driver(). This appears necessary when
>>>>> using
>>>>> the USB gadget framework in U-Boot, since that does not allocate/free
>>>>> the EP0 request. However, the CDC Ethernet driver *does* allocate and
>>>>> free its own EP0 requests. Consequently, we must protect
>>>>> ci_ep_free_request() against double-freeing the request.
>>
>>
>>
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>