Re: [PATCH 1/2] usb: dwc2: handle NAK when CHHLTD does not fire

[anis chali <chalianis1@gmail.com>]

Hi.

On Raspberry pi cm 4, with only the patch usb: dwc2: handle NAK when
CHHLTD does not fire,
the usb controller does not work and displays indefinitely the message
below even if no usb storage plugged in
ERROR: dwc2 fe980000.usb@7e980000.of: Timeout on bulk endpoint
I did the test with the patch series and I get the same behaviour,
console continuously displaying the timeout error.

Thank's.
Anis C.

Le lun. 20 avr. 2026 à 11:40, anis chali <chalianis1@gmail.com> a écrit :
>
> Hi, Okay I will give it a try today and come back to you.
>
> Anis C.
>
> Le lun. 20 avr. 2026 à 10:11, Ahmad Fatoum <a.fatoum@pengutronix.de> a écrit :
> >
> > Hi,
> >
> > fixing the Cc.
> >
> > On 4/20/26 2:18 PM, Sascha Hauer wrote:
> > > +Cc Chali Anis <chalianis1@gmail.com>
> > >
> > > On Mon, Apr 20, 2026 at 01:32:25PM +0200, Ahmad Fatoum wrote:
> > >> Hello,
> > >>
> > >> On 4/20/26 1:20 PM, Sascha Hauer wrote:
> > >>> From: Sascha Hauer <sascha@saschahauer.de>
> > >>>
> > >>> Some DWC2 configurations do not assert CHHLTD when a NAK is received;
> > >>> the hardware keeps the channel active and only sets the NAK bit in HCINT.
> > >>> wait_for_chhltd() polls for CHHLTD with a 10ms timeout; when CHHLTD never
> > >>> fires the timeout expires and -ETIMEDOUT is returned without inspecting
> > >>> HCINT. This causes the caller to treat the NAK as a hard error instead of
> > >>> a retryable condition.
> > >>>
> > >>> The symptom is that devices which NAK bulk or control transfers during
> > >>> initialisation (e.g. some Samsung USB-C flash drives that NAK while their
> > >>> firmware starts up) fail immediately rather than being retried via the
> > >>> 5-second NAK-retry loop in dwc2_submit_bulk_msg() or the do/while loops
> > >>> in dwc2_submit_control_msg().
> > >>>
> > >>> Fix by reading HCINT before aborting the channel when the CHHLTD timeout
> > >>> fires. If the NAK or FRMOVRUN bit is set, abort the channel, wait for the
> > >>> abort to complete, and return -EAGAIN so that the existing retry logic can
> > >>> handle the NAK. Log a diagnostic message if the channel abort itself times
> > >>> out, which would indicate a real hardware problem.
> > >>
> > >> How does this relate to
> > >> https://lore.barebox.org/barebox/20260331034819.227094-1-chalianis1@gmail.com/
> > >>
> > >> Do we need both? Only this one? Is there something over there, which you
> > >> would want in your series?
> > >
> > > Sounds related, but seems to be a different issue. It says "handle the case where
> > > DMA has already completed by the time we get here". DMA is not an issue
> > > in my case. We likely need a combination of both, but Chali, could you
> > > give my patch without yours a try to see if it changes something for
> > > good in your case?
> > >
> > > Sascha
> > >
> >
> > --
> > Pengutronix e.K.                  |                             |
> > Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> > 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> >