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

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

On 11/3/2026 8:41 AM, Thinh Nguyen wrote:
> Hi,
> 
> Sorry for the delay, I was out of office.
> 
> On Wed, Oct 28, 2026, Krishna Kurapati wrote:
>>
>> On 10/21/2026 7:31 AM, Thinh Nguyen wrote:
>>>
>>> I'd rather not take this without testing. The check adds a register read
>>> to every endpoint command and implies that CSR timeout is expected
>>> during command sending, which it shouldn't be. Without confirmation that
>>> it catches the issue and that recovery works, that cost is not
>>> justified.
>>>
>>
>> I won't be able to test this in my environment. The only PIPO test that
>> easily reproduced it easily was with one faulty cable from (IIRC Xiaomi) and
>> CDP port of AMD based Lenovo laptop (there was a particular variant, I will
>> find out). I don't have that faulty cable for now, but this issue was
>> reported even on Kaanapali as well on 6.12 Kernel (mobile build). Not sure
>> if I can provide this series along with err_recovery_work to OEM and get the
>> results since this is reproducible with very difficulty on their end too.
>>
>> How about we add the Depcmd check and then the GSTS check inside it ? To
>> avoid checking GSTS always.
> 
> Your report shows ENDXFER timing out with CMDACT still set, so the
> DEPCMD read back may not show a mismatch, and GSTS would never be
> checked. To avoid reading GSTS on every command, we could check it
> only when the command times out instead.
> 
> I'm fine with this approach. Since it's hard to reproduce, please note
> in the commit message that it's untested against the failure, and add
> a dev_err when it triggers so we can confirm it when it does happen.
> 
>>
>>> Also, looking at the original report again, the stuck state could start
>>> without an endpoint command being issued. Unplugging the cable then gave
>>> no disconnect event, which blocked suspend. A check only in
>>> dwc3_send_gadget_ep_cmd() wouldn't catch that.
>>>
>>
>> Currently on downstream, the way we work is that if we unplug the cable we
>> expect the controller enter runtime suspend. If that doesn't happen and the
>> controller is stuck, we do a "usb_gadget_disconnect(dwc->gadget)" and then
>> upon re-connect we do a "usb_gadget_connect(dwc->gadget)". So, if upon any
>> plug-in, if enumeration fails and if we encounter this scenario, we are not
>> handling this until plug out is done.
>>
> 
> How do you detect that it's stuck? Soft-connect already does a core soft
> reset, so you could call usb_gadget_connect() right away instead of
> waiting for re-connect.
> 
> Would be great if you have logs showing a consistent symptom (GSTS,
> DSTS, DEPCMD read back) that we can check for.

Will dig up my mails. I remember having logged the registers when 
discussing this issue with synopsys.

Regards,
Krishna,

> 
> BR,
> Thinh