From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 27 Jun 2014 15:56:58 -0600 Subject: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC In-Reply-To: <53ADE78C.4020601@posteo.de> References: <1403546568-30830-1-git-send-email-swarren@wwwdotorg.org> <201406251551.29728.marex@denx.de> <53AAF389.3010204@wwwdotorg.org> <53ADE412.5060902@posteo.de> <53ADE78C.4020601@posteo.de> Message-ID: <53ADE8AA.8070907@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>> >>>>> 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 >