From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg_Krause?= Date: Fri, 27 Jun 2014 23:52:12 +0200 Subject: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC In-Reply-To: <53ADE412.5060902@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> Message-ID: <53ADE78C.4020601@posteo.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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 >>>> >>>> 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