On 3/9/21 10:32 AM, Ye Li wrote:
Hi Marek,
Hi,
[...]
+ 10 * 1000); /* 10ms timeout */
+ if (ret < 0)
+ printf("EHCI fail timeout STS_IAA set\n");
Shouldn't there be some abort ^ if ret < 0 ?
Also, add the return value into the printf, it is useful for
debugging.
I don't think need to abort anything when ret < 0. The ret value is
very simple in handshake, when ret < 0, it must be -1.
Actually the codes refer the ehci_enable_async for the usage of
handshake.
If the handshake timed out, that indicates a problem and that problem
shouldn't be ignored, but rather propagated, no ? Maybe the entire
ehci
transfer should be aborted ?
I supposed the problem means QH does not advance, so next submit of
async transfer will have QTD timeout. But it is ok to abort transfer as
the error handling.
If this is an error which would always cause subsequent error, abort
here already.
+ ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA);
+
+ return ret;
+}
Is this a bugfix for this release or is this for next release ?
We're in rc3 already, so I would suggest to be careful.
It is ok to add the fix for next release. From our tests, the issue
is
not very easy to reproduce by just using usb read/write. In
SCT, generally we need to run about 1 hour to see the issue.
Can you add details on how to reproduce the issue into the commit
message ? That would be highly helpful.
ok. I will add more.
Thank you
