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

Jörg Krause jkrause at posteo.de
Fri Jun 27 23:52:12 CEST 2014


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


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



More information about the U-Boot mailing list