Re: [PATCH v3] usb: dwc3: core: Fix RAM interface getting stuck during enumeration

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Tue, Oct 13, 2026, Krishna Kurapati wrote:
> 
> 
> On 9/29/2026 10:49 AM, Krishna Kurapati wrote:
> > During plug-in/plug-out test cases, it is sometimes seen that no events
> > are generated by the controller and all CSR register reads give "0" and
> > CSR_Timeout bit gets set indicating that CSR reads/writes are timing out
> > or timed out.
> > 
> > The issue comes up on different instnaces of enumeration on different
> > platforms. On SM8550, the debug log is as follows:
> > 
> > Prepared a TRB on ep0out and did start transfer to get set
> > address request from host:
> > 
> > <...>-7191    [000] D..1.    66.421006: dwc3_gadget_ep_cmd: ep0out:
> > cmd 'Start Transfer' [406] params 00000000 efffa000 00000000 -->
> > status: Successful
> > 
> > <...>-7191    [000] D..1.    66.421196: dwc3_event: event (0000c040):
> > ep0out: Transfer Complete (sIL) [Setup Phase]
> > 
> > <...>-7191    [000] D..1.    66.421197: dwc3_ctrl_req: Set
> > Address(Addr = 01)
> > 
> > An XFER NRDY is received on ep0in for zero length status phase and
> > a Start Transfer was done on ep0in with 0-length packet in 2 Stage
> > status phase:
> > 
> > <...>-7191    [000] D..1.    66.421249: dwc3_event: event (000020c2):
> > ep0in: Transfer Not Ready [00000000] (Not Active) [Status Phase]
> > 
> > <...>-7191    [000] D..1.    66.421266: dwc3_prepare_trb: ep0in: trb
> > ffffffc00fcfd000 (E0:D0) buf 00000000efffa000 size 0 ctrl 00000c33
> > sofn 00000000 (HLcs:SC:status2)
> > 
> > <...>-7191    [000] D..1.    66.421387: dwc3_gadget_ep_cmd: ep0in: cmd
> > 'Start Transfer' [406] params 00000000 efffa000 00000000 -->status:
> > Successful
> > 
> > A bus reset was then received directly after 500 msec. Software never
> > got the cmd complete for the start transfer done in status phase. Here
> > the RAM interface is stuck. So host issues a bus reset as link is
> > idle for 500 msec:
> > 
> > <...>-7191    [000] D..1.    66.935603: dwc3_event: event (00000101):
> > Reset [U0]
> > 
> > Then software sees that it is in status phase and we issue an ENDXFER
> > on ep0in and it gets timedout waiting for the CMDACT to go '0':
> > 
> > <...>-7191    [000] D..1.    66.958249: dwc3_gadget_ep_cmd: ep0in: cmd
> > 'End Transfer' [10508] params 00000000 00000000 00000000 --> status:
> > Timed Out
> > 
> > Upon debug with Synopsys, the root cause is as follows:
> > 
> > During any transfer, if the data is not successfully transmitted,
> > then a Done (with failure) handshake is returned, so that the BMU
> > can re-attempt the same data again by rewinding its data pointers.
> > 
> > But, if the USB IN is a 0-length payload (which is what is happening
> > in this case - 2 stage status phase of set_address), then there is no
> > need to rewind the pointers and the Done (with failure) handshake is
> > not returned for failure case. This keeps the Request-Done interface
> > busy till the next Done handshake. The MAC sends the 0-length payload
> > again when the host requests. If the transmission is successful this
> > time, the Done (with success) handshake is provided back. Otherwise,
> > it repeats the same steps again.
> > 
> > If the cable is disconnected or if the Host aborts the transfer on 3
> > consecutive failed attempts, the Request-Done handshake is not
> > complete. This keeps the interface busy.
> > 
> > The subsequent RAM access cannot proceed until the above pending
> > transfer is complete. This results in failure of any access to RAM
> > address locations. Many of the EndPoint commands need to access the
> > RAM and they would fail to complete successfully.
> > 
> > Furthermore when cable removal happens, this would not generate a
> > disconnect event and the "connected" flag remains true always blockin
> > suspend.
> > 
> > Synopsys confirmed that the issue is present on all USB3 devices and
> > as a workaround, suggested to re-initialize device mode.
> > 
> > Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> 
> 
> Thinh, Can you help provide your review on this patch.
> 

Hi Krishna,

If the CSR_Timeout bit is set, why not check GSTS.CSRTimeout directly
instead of indirectly checking DEPCMD type mismatch?

Also, shouldn't we return an error code instead of success if need to
schedule recovery?

Thanks,
Thinh