From: "Jörg Krause" <jkrause@posteo.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
Date: Fri, 27 Jun 2014 23:52:12 +0200 [thread overview]
Message-ID: <53ADE78C.4020601@posteo.de> (raw)
In-Reply-To: <53ADE412.5060902@posteo.de>
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@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
next prev parent reply other threads:[~2014-06-27 21:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 18:02 [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC Stephen Warren
2014-06-23 19:03 ` Eric Nelson
2014-06-25 13:51 ` Marek Vasut
2014-06-25 16:06 ` Stephen Warren
2014-06-27 21:37 ` Jörg Krause
2014-06-27 21:52 ` Jörg Krause [this message]
2014-06-27 21:56 ` Stephen Warren
2014-06-27 23:27 ` Jörg Krause
2014-06-27 21:55 ` Stephen Warren
2014-06-27 23:16 ` Jörg Krause
2014-06-27 23:37 ` Stephen Warren
2014-06-28 0:09 ` Jörg Krause
2014-06-28 1:34 ` Jörg Krause
2014-06-28 20:37 ` Jörg Krause
2014-06-28 20:45 ` Marek Vasut
2014-06-28 20:53 ` Jörg Krause
2014-06-29 20:33 ` Jörg Krause
2014-06-30 9:37 ` Marek Vasut
2014-06-30 13:34 ` Jörg Krause
2014-06-30 16:02 ` Stephen Warren
2014-06-30 19:55 ` Stephen Warren
2014-06-30 22:44 ` Jörg Krause
2014-06-30 22:51 ` Stephen Warren
2014-06-30 23:17 ` Jörg Krause
2014-06-30 23:56 ` Marek Vasut
2014-06-30 20:55 ` Jörg Krause
2014-06-30 21:15 ` Marek Vasut
2014-06-30 21:43 ` Jörg Krause
2014-06-30 21:50 ` Marek Vasut
2014-06-25 20:20 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53ADE78C.4020601@posteo.de \
--to=jkrause@posteo.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox