On 18-11-2022 03:11, Thinh Nguyen wrote:
On Thu, Nov 17, 2022, Ferry Toth wrote:
Since commit 0f010171
I don't your update as noted in the v3 change (ie. Greg's suggestions).
Indeed. I seem to have sent in the wrong sha. Sorry about this.
Dual Role support on Intel Merrifield platform broke due to rearranging
the call to dwc3_get_extcon().
It appears to be caused by ulpi_read_id() masking the timeout on the first
test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset()
followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER.
On deferred probe ulpi_read_id() finally succeeded.
As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we
need to handle the error by calling dwc3_core_soft_reset() and request
-EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds.
Signed-off-by: Ferry Toth <ftoth@xxxxxxxxxxxxxx>
---
drivers/usb/dwc3/core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 648f1c570021..2779f17bffaf 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1106,8 +1106,13 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (!dwc->ulpi_ready) {
ret = dwc3_core_ulpi_init(dwc);
- if (ret)
+ if (ret) {
+ if (ret == -ETIMEDOUT) {
+ dwc3_core_soft_reset(dwc);
I'm not sure if you saw my previous response. I wanted to check to see
if we need to do soft-reset once before ulpi init as part of its
initialization.
I missed it but found it now. I will try your suggestion and answer.
I'm just curious why Andrey Smirnov test doesn't require this change. If
it's a quirk for this specific configuration, then the change here is
fine. If it's required for all ULPI setup, then we can unconditionally
do that for all ULPI setup during initialization.
Yes me too. I can reproduce that when I build kernel and rootfs with
buildroot there is no issue. But as soon as I add ftrace / bootconfig
the issue appears and then I can't analyze the flow. It's seems some
kind of timing / race.
However, I have tried deferring without dwc3_core_soft_reset() (to
verify if it is just a matter of time) and that doesn't work. dwc3 is
deferred about 10x and then gives up without phy. So, it's not just the
time and not just a matter of retrying the test write.
+ ret = -EPROBE_DEFER;
+ }
goto err0;
+ }
dwc->ulpi_ready = true;
}
--
2.37.2
Thanks,
Thinh
