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

[Thinh Nguyen]

On Wed, Oct 07, 2026, Elson Serrao wrote:
> 
> 
> On 10/1/2026 5:48 PM, Thinh Nguyen wrote:
> > On Thu, Oct 01, 2026, Elson Serrao wrote:
> >> The controller clears DCTL.CSFTRST only after all required logic has
> >> been reset and all PHY clocks are active. If SUSPHY remains set, the PHY
> >> may not be fully active during the reset sequence, causing the core soft
> >> reset to fail to complete.
> >>  
> >> Clear SUSPHY before asserting DCTL.CSFTRST to ensure the PHY remains
> >> active while the reset is in progress.
> >>
> >> Fixes: cc5bfc4e16fc ("usb: dwc3: Set SUSPENDENABLE soon after phy init")
> >> Signed-off-by: Elson Serrao <elson.serrao@xxxxxxxxxxxxxxxx>
> >> ---
> >>  drivers/usb/dwc3/core.c | 7 +++++++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> >> index fd5c2cd36c59..282a853c364e 100644
> >> --- a/drivers/usb/dwc3/core.c
> >> +++ b/drivers/usb/dwc3/core.c
> >> @@ -332,6 +332,13 @@ int dwc3_core_soft_reset(struct dwc3 *dwc)
> >>  	if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
> >>  		return 0;
> >>  
> >> +	/*
> >> +	 * The core clears DCTL.CSFTRST only after all necessary logic is
> >> +	 * reset and all PHY clocks are active/running. Clear SUSPHY before
> >> +	 * issuing the reset so that the PHY is active.
> >> +	 */
> >> +	dwc3_enable_susphy(dwc, false);
> >> +
> >>  	reg = dwc3_readl(dwc, DWC3_DCTL);
> >>  	reg |= DWC3_DCTL_CSFTRST;
> >>  	reg &= ~DWC3_DCTL_RUN_STOP;
> >> -- 
> >> 2.34.1
> >>
> > 
> > Most platforms require SUSPHY to be set before soft reset. Can you
> > handle this via a pre_soft_reset() glue_ops for the affected platform
> > instead?
> > 
> Hi Thinh,
>  
> Thank you for the feedback and suggestion. I will explore that
> approach further and evaluate whether a pre_soft_reset() glue_ops
> hook can be used.
>  
> One point I'm still trying to understand is that the programming guide
> states that DCTL.CSFTRST is cleared only after all PHY clocks are
> active/running. Based on that description, suspending the PHY during
> the core soft reset sequence seems somewhat counterintuitive, as reset
> completion appears to depend on an active PHY clock.
>  
> Am I missing something in how SUSPHY is expected to interact with the
> PHY clocking requirements during core soft reset?
>  

Maybe I should retract the statement that "most platforms" require this,
since the behavior depends on the PHY.

From what I recall, certain PHYs, particularly those integrated with a
type-c controller/TCA may require certain suspend clocks running so PHY
operations can be executed. On those platforms, the PHY and the usb
controller need to coordinate during the initial soft reset and
initialization sequence.

So, IMHO, we should not clear SUSPHY unconditionally before every soft
reset, even if it is required for a particular platform. The existing
behavior has been validated on many platforms, and changing it now
risks regressions.

BR,
Thinh