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

[Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>]

On 10/14/2026 7:14 AM, Thinh Nguyen wrote:
> 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?
> 

As per discussion on [1], implemented this checking of DEPCMD registers. 
Let me know if reading GSTS is a better option here. Will send v4 
accordingly.

> Also, shouldn't we return an error code instead of success if need to
> schedule recovery?
> 
I think that is done while queueing recovery work:
dwc->err_state = DWC3_ERR_RECOVERY;

[1]: 
https://lore.kernel.org/all/20231020225349.ocvyxt5opw4y5bl6@synopsys.com/

Regards,
Krishna,