Hi Simon, Thanks a lot for reviewing the issue.
>>> With respect to using a bulk USB stick (some of which take 3s or more >>> to respond to a submit) this doesn't make any difference for me. It >>> seems to take a long time to respond the first time, so the 5s timeout >>> seems prudent. >>> >>> Since this sorts out the network side we can probably skip that patch. >>> >> >> Are you suggesting we revert the patch you had submitted [2], instead >> of deleting the goto line as done in my patch? I think it would be >> better if we left [2] in and allowed the async disable to happen after >> a timeout like I'm doing. >> >> There are other patches that are reported to fix the issue such as [3] >> and [4], but I think they are more like workarounds and delay the >> occurrence of the event of a timeout itself. A timeout which would >> occur for any other reason such as too many USB devices connected to >> the hub can trigger the problem, and, not running async schedule and >> the other code after the timeout seems to make EHCI unrecoverable. > > My feeling was that the time was more a function of the device that is > plugged in than the USB port/peripheral. Perhaps someone will find a > device which needs a 10s timeout, so I agree just increasing it is not > really the solution. > > I found that once the device timed out it needed a reset to work - > just resubmitting the urb didn't work for me. Maybe I had some other > problem. > > Anyway I think your patch looks good, thank you. > Could I add your Acked-by to the submission as well? thanks, Joel _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot