Hi Mattijs,
Sorry for late reply.
On 7/24/2026 7:12 PM, Mattijs Korpershoek wrote:
Hi Balaji,
Thank you for the patch.
On Fri, Jul 24, 2026 at 14:58, Balaji Selvanathan
<[email protected]> wrote:
This reverts commit 6de333b5caf035c38d7af9fa7596aeffcc49db42.
The delay is unnecessary. Upstream Linux does not add this delay after
the core soft reset and the USB works fine without it.
Tested in QCS6490 RB3Gen2 Qualcomm board.
Signed-off-by: Balaji Selvanathan <[email protected]>
---
- This is part of ongoing initiative to reduce boot time across all
Qualcomm boards. So we can remove this unnecessary delay.
- Actually, this delay was removed in the Kodiak v4 series:
https://lore.kernel.org/u-boot/[email protected]/
but v3 series got picked up:
https://lore.kernel.org/u-boot/177745255938.126665.16625119085748603933.b4-ty@b4/
---
drivers/usb/dwc3/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index be198041f08..ae22e1c792d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -106,8 +106,6 @@ done:
if (DWC3_VER_IS_WITHIN(DWC31, ANY, 180A))
mdelay(50);
- mdelay(100);
-
The dwc3 driver is not only used by qualcomm, but many other SoCs.
That delay indeed does not exist as is in the Linux driver since the
following commit f59dcab17629 ("usb: dwc3: core: improve reset sequence")
Yes, this delay doesn't exist in Linux driver and the delay was added by
me in 6de333b5caf035c38d7af9fa7596aeffcc49db42.
But found later that this delay is actually not required and hence would
like to revert it. Have tested the revert on QCM6490 and USB inits fine.
However, that commit is more conservative by adding retries and such.
I'd prefer to stick with Linux's approach here.
Also note, there is an ongoing effort of updating the dwc3 driver by
Linaro here:
https://lore.kernel.org/all/[email protected]/
Could you maybe give that a try? It should have the
"usb: dwc3: core: improve reset sequence" patch in there.
I agree the Linaro series is the right long-term fix, since it carries
the retry-based approach from Linux rather than a flat delay.
That series touches a fair amount of the reset sequence though, and it
may take a while to land upstream.
Given that, would you be open to taking this revert now as an interim
fix, since it's tested not to regress the platform it was added for?
Regards,
Balaji
return 0;
}
---
base-commit: d7ef23c07b8e34f65b3e15e3b4e7f58d074923c8
change-id: 20260724-kodiak_delay-a5f1e8b675cd
Best regards,
--
Balaji Selvanathan <[email protected]>
