[PATCH 0/2] USB: dwc2: Fix handling NAK

[PATCH 0/2] USB: dwc2: Fix handling NAK

[Sascha Hauer]

A NAK should return -EAGAIN to let the retry logic work. This showed up
on a Samsung USB-C memory stick which otherwise was recognized, but
couldn't be initialized.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Sascha Hauer (2):
      usb: dwc2: handle NAK when CHHLTD does not fire
      usb: dwc2: fix data toggle reset direction on ClearFeature(ENDPOINT_HALT)

 drivers/usb/dwc2/host.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
---
base-commit: 92d9725c3945aff9d157531be844fa256444165d
change-id: 20260420-usb-dwc2-usb-c-stick-ea31c736477c

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>

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

[Sascha Hauer]

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.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Sascha Hauer <sascha@saschahauer.de>
---
 drivers/usb/dwc2/host.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/host.c b/drivers/usb/dwc2/host.c
index 93994f0be3..ddad51c882 100644
--- a/drivers/usb/dwc2/host.c
+++ b/drivers/usb/dwc2/host.c
@@ -134,9 +134,14 @@ static int wait_for_chhltd(struct dwc2 *dwc2, u8 hc, uint32_t *sub, u8 *tgl)
 
 	ret = dwc2_wait_bit_set(dwc2, HCINT(hc), HCINTMSK_CHHLTD, 10000);
 	if (ret) {
+		hcint = dwc2_readl(dwc2, HCINT(hc));
 		hcchar = dwc2_readl(dwc2, HCCHAR(hc));
 		dwc2_writel(dwc2, hcchar | HCCHAR_CHDIS, HCCHAR(hc));
-		dwc2_wait_bit_set(dwc2, HCINT(hc), HCINTMSK_CHHLTD, 10000);
+		if (dwc2_wait_bit_set(dwc2, HCINT(hc), HCINTMSK_CHHLTD, 10000))
+			dwc2_err(dwc2, "%s: channel abort timed out: HCINT=%08x HCCHAR=%08x\n",
+				 __func__, hcint, hcchar);
+		if (hcint & (HCINTMSK_NAK | HCINTMSK_FRMOVRUN))
+			return -EAGAIN;
 		return ret;
 	}
 

-- 
2.47.3

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

[Ahmad Fatoum]

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?

Thanks,
Ahmad

> 
> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
> Signed-off-by: Sascha Hauer <sascha@saschahauer.de>
> ---
>  drivers/usb/dwc2/host.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/host.c b/drivers/usb/dwc2/host.c
> index 93994f0be3..ddad51c882 100644
> --- a/drivers/usb/dwc2/host.c
> +++ b/drivers/usb/dwc2/host.c
> @@ -134,9 +134,14 @@ static int wait_for_chhltd(struct dwc2 *dwc2, u8 hc, uint32_t *sub, u8 *tgl)
>  
>  	ret = dwc2_wait_bit_set(dwc2, HCINT(hc), HCINTMSK_CHHLTD, 10000);
>  	if (ret) {
> +		hcint = dwc2_readl(dwc2, HCINT(hc));
>  		hcchar = dwc2_readl(dwc2, HCCHAR(hc));
>  		dwc2_writel(dwc2, hcchar | HCCHAR_CHDIS, HCCHAR(hc));
> -		dwc2_wait_bit_set(dwc2, HCINT(hc), HCINTMSK_CHHLTD, 10000);
> +		if (dwc2_wait_bit_set(dwc2, HCINT(hc), HCINTMSK_CHHLTD, 10000))
> +			dwc2_err(dwc2, "%s: channel abort timed out: HCINT=%08x HCCHAR=%08x\n",
> +				 __func__, hcint, hcchar);
> +		if (hcint & (HCINTMSK_NAK | HCINTMSK_FRMOVRUN))
> +			return -EAGAIN;
>  		return ret;
>  	}
>  
> 

-- 
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 |

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

[Sascha Hauer]

+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 |

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

[Ahmad Fatoum]

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 |

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

[anis chali]

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 |
>

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

[anis chali]

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 |
> >

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

[Sascha Hauer]

Hi,

On Mon, Apr 20, 2026 at 10:28:58PM -0400, anis chali wrote:
> 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.

I just tried with only your patch applied and it doesn't work for me. It
seems there is some timing issue involved, because when I add debugging
output at the right places then it works.

I haven't gotten further so far.

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 |

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

[anis chali]

Hi,

Le mar. 21 avr. 2026 à 03:54, Sascha Hauer <s.hauer@pengutronix.de> a écrit :
>
> Hi,
>
> On Mon, Apr 20, 2026 at 10:28:58PM -0400, anis chali wrote:
> > 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.
>
> I just tried with only your patch applied and it doesn't work for me. It
> seems there is some timing issue involved, because when I add debugging
> output at the right places then it works.

Do you have logs, to check whether I had the same ?
I got the same behaviour when I added debugging messages.
We maybe try a combination or add the retry.

> I haven't gotten further so far.
>
> 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 |

Anis C.

[PATCH 2/2] usb: dwc2: fix data toggle reset direction on ClearFeature(ENDPOINT_HALT)

[Sascha Hauer]

From: Sascha Hauer <sascha@saschahauer.de>

dwc2_submit_control_msg() resets the data toggle after a successful
ClearFeature(ENDPOINT_HALT) request. It passes usb_pipein(pipe) as the
direction to dwc2_endpoint_reset(), but pipe is always the control-out
pipe used to send the request, so usb_pipein() always returns 0 (OUT).

As a result, clearing an IN endpoint halt resets the OUT toggle instead
of the IN toggle, leaving the IN data toggle in an incorrect state for
subsequent transfers.

Fix by extracting the direction from the endpoint address in setup->index
(wIndex), where bit 7 is the direction flag per USB 2.0 section 9.3.4.

Fixes: 446bcf875395 ("usb: dwc2: host: Fix toggle reset")
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Sascha Hauer <sascha@saschahauer.de>
---
 drivers/usb/dwc2/host.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/host.c b/drivers/usb/dwc2/host.c
index ddad51c882..2be2666574 100644
--- a/drivers/usb/dwc2/host.c
+++ b/drivers/usb/dwc2/host.c
@@ -401,8 +401,8 @@ static int dwc2_submit_control_msg(struct usb_device *udev,
 		 * ClearFeature(ENDPOINT_HALT) request always results
 		 * in the data toggle being reinitialized to DATA0.
 		 */
-		int ep = le16_to_cpu(setup->index) & 0xf;
-		dwc2_endpoint_reset(dwc2, usb_pipein(pipe), devnum, ep);
+		int ep_addr = le16_to_cpu(setup->index);
+		dwc2_endpoint_reset(dwc2, ep_addr >> 7, devnum, ep_addr & 0xf);
 	}
 
 	udev->act_len = act_len;

-- 
2.47.3