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

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

On 10/15/2026 7:42 AM, Thinh Nguyen wrote:
> On Wed, Oct 14, 2026, Krishna Kurapati wrote:
>>
>>
>> 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.
> 
> At the time, my understanding was that all register reads return 0 in
> this state as noted in that conversation. However, based on your commit
> message and the databook, GSTS is still accessible and CSRTimeout is
> set. Also, on CSR timeout, the read data is residue from a previous read
> and isn't guaranteed to be 0. So the DEPCMD read back isn't reliable.
> 
> Can you check GSTS.CSRTimeout after the CMDACT polling instead?
> Something like this:
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index ee837235630a..ff4957a7311e 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -283,6 +283,8 @@ int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
>   	return ret;
>   }
>   
> +static void dwc3_schedule_err_recovery(struct dwc3 *dwc);
> +
>   /**
>    * dwc3_send_gadget_ep_cmd - issue an endpoint command
>    * @dep: the endpoint to which the command is going to be issued
> @@ -432,6 +434,14 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd,
>   		cmd_status = -ETIMEDOUT;
>   	}
>   
> +	reg = dwc3_readl(dwc, DWC3_GSTS);
> +	if (reg & DWC3_GSTS_CSR_TIMEOUT) {
> +		dwc3_writel(dwc, DWC3_GSTS, DWC3_GSTS_CSR_TIMEOUT);
> +		ret = -ETIMEDOUT;
> +		cmd_status = -ETIMEDOUT;
> +		dwc3_schedule_err_recovery(dwc);
> +	}
> +
>   skip_status:
>   	trace_dwc3_gadget_ep_cmd(dep, cmd, params, cmd_status);
>   

I don't have the apparatus to reproduce this issue at my end currently 
and extremely difficult to reproduce at customer end. Will send this 
diff along with your suggested-by tag if that is fine.

> 
>>
>>> 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;
>>
> 
> That only blocks new requests. The current call still returns 0, so the
> caller still sees the command as success.
> 

ACK.

Regards,
Krishna,