[RFC PATCH 0/1] usb: dwc3: Clear SUSPHY before issuing core soft reset

[Elson Serrao]

We are running into an issue where the DWC3 core soft reset consistently
times out when snps,dis_u2_susphy_quirk is not present.
 
We recently dropped this quirk on our targets to allow SUSPHY to remain
enabled during host/gadget exit paths and avoid controller faults, as
part of the changes introduced in [1]. However, this exposed another
issue where dwc3_core_soft_reset() fails when SUSPHY remains enabled.
 
The failure is seen during the following sequence:
 
[  126.110298] [0:    kworker/0:3:  671] dwc3 a600000.dwc3: DWC3 controller soft reset failed.
[  126.110347] [0:    kworker/0:3:  671]  dwc3_core_soft_reset+0x3b8/0x568
[  126.110352] [0:    kworker/0:3:  671]  dwc3_core_init+0x900/0x17d4
[  126.110356] [0:    kworker/0:3:  671]  dwc3_resume_common+0x5c/0x394
[  126.110360] [0:    kworker/0:3:  671]  dwc3_plat_runtime_resume+0x28/0x88
[  126.110365] [0:    kworker/0:3:  671]  pm_generic_runtime_resume+0x44/0x5c
[  126.110369] [0:    kworker/0:3:  671]  __rpm_callback+0x94/0x3b0
[  126.110373] [0:    kworker/0:3:  671]  rpm_resume+0x43c/0x64c
[  126.110377] [0:    kworker/0:3:  671]  __pm_runtime_resume+0x6c/0xb0
[  126.110380] [0:    kworker/0:3:  671]  __dwc3_set_mode+0x48/0x580
 
This occurs before PRTCAP is programmed, where mode-switching
code already explicitly disables SUSPHY as needed.
 
The attached patch clears SUSPHY at the beginning of
dwc3_core_soft_reset() so that the PHY remains active while the reset
is pending.
 
I would appreciate feedback on whether this approach is reasonable and if
there is a preferred way to handle this.
 
Thanks,
Elson
 
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1003aa7ec9eccdde4c926bd64ef42816ad55f25

Elson Serrao (1):
  usb: dwc3: Clear SUSPHY before issuing core soft reset

 drivers/usb/dwc3/core.c | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
2.34.1