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

[Krishna Kurapati]

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