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

[Thinh Nguyen]

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.

BR,
Thinh