public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] USB: max3421: Fix retransmit handling and scheduling while atomic
@ 2025-02-10  5:06 Matt Lee
  2025-02-10  6:13 ` Greg KH
  0 siblings, 1 reply; 2+ messages in thread
From: Matt Lee @ 2025-02-10  5:06 UTC (permalink / raw)
  To: linux-usb; +Cc: gregkh, matt


[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]

This patch series addresses two issues in the max3421 USB host controller
driver:

1. **Patch 1** This patch reverts the removal of the slow retransmit of NAK
responses.  This fixes some USB accessories from becoming unresponsive.

2. **Patch 2** fixes a "scheduling while atomic" bug in `max3421_remove()`
by ensuring that `kthread_stop()` is called outside a spinlock, preventing
a system crash when removing the driver or shutting down.

Both patches have been tested on a BCM2711 with MAX3421 hardware.

Kind regards,
Matt Lee
matt@oscium.com

---

**Patches:**
**[PATCH 1/2] USB: max3421: Fix retransmit handling for NAK responses**
**[PATCH 2/2] USB: max3421: Fix scheduling while atomic in
max3421_remove()**

[-- Attachment #1.2: Type: text/html, Size: 857 bytes --]

[-- Attachment #2: 0001-USB-max3421-Fix-retransmit-handling.patch --]
[-- Type: application/octet-stream, Size: 1898 bytes --]

From: Your Name <matt@oscium.com>
Subject: [PATCH 1/2] USB: max3421: Improve retransmit handling for NAK responses

This reverts a previouisly submitted patch where the slow retransmit was removed.

Previously, the max3421 driver would immediately retry transmissions indefinitely 
upon receiving a NAK response, leading to potential stalls.

This patch re-introduces a limit (`NAK_MAX_FAST_RETRANSMITS`) on how many times a 
request is retransmitted immediately.  After reaching this limit, the driver 
falls back to a slower retransmit strategy using `max3421_slow_retransmit()`.

This improves robustness when dealing with unresponsive USB devices.

Signed-off-by: Matt Lee <matt@oscium.com>
---
 drivers/usb/host/max3421-hcd.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index 1234567..abcdef0 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -72,6 +72,12 @@
 #define USB_MAX_FRAME_NUMBER   0x7ff
 #define USB_MAX_RETRIES        3 /* # of retries before error is reported */

+/*
+ * Max. # of times we're willing to retransmit a request immediately in
+ * response to a NAK.  Afterwards, we fall back on trying once a frame.
+ */
+#define NAK_MAX_FAST_RETRANSMITS       2
+
 #define POWER_BUDGET   500     /* in mA; use 8 for low-power port testing */

 /* Port-change mask: */
@@ -924,8 +930,11 @@ max3421_handle_error(struct usb_hcd *hcd
                 * Device wasn't ready for data or has no data
                 * available: retry the packet again.
                 */
+               if (max3421_ep->naks++ < NAK_MAX_FAST_RETRANSMITS) {
                max3421_next_transfer(hcd, 1);
                switch_sndfifo = 0;
+               } else
+                       max3421_slow_retransmit(hcd);
                break;
        }
        if (switch_sndfifo)
-- 
2.34.1


[-- Attachment #3: 0002-USB-max3421-Fix-scheduling-while-atomic.patch --]
[-- Type: application/octet-stream, Size: 1101 bytes --]

From: Matt Lee <matt@oscium.com>
Subject: [PATCH 2/2] USB: max3421: Fix scheduling while atomic in max3421_remove()

A bug in `max3421_remove()` caused a "scheduling while atomic" crash when 
`kthread_stop()` was called while holding a spinlock.

This patch ensures that `kthread_stop()` is called outside the spinlock, 
fixing the crash and improving system stability when unloading the driver.

Signed-off-by: Matt Lee <matt@oscium.com>
---
 drivers/usb/host/max3421-hcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index abcdef0..1234567 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1936,11 +1945,10 @@ max3421_remove(struct spi_device *spi)
        usb_remove_hcd(hcd);

        spin_lock_irqsave(&max3421_hcd->lock, flags);
+       spin_unlock_irqrestore(&max3421_hcd->lock, flags);

        kthread_stop(max3421_hcd->spi_thread);

-       spin_unlock_irqrestore(&max3421_hcd->lock, flags);
-
        free_irq(spi->irq, hcd);

        usb_put_hcd(hcd);
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH 0/2] USB: max3421: Fix retransmit handling and scheduling while atomic
  2025-02-10  5:06 [PATCH 0/2] USB: max3421: Fix retransmit handling and scheduling while atomic Matt Lee
@ 2025-02-10  6:13 ` Greg KH
  0 siblings, 0 replies; 2+ messages in thread
From: Greg KH @ 2025-02-10  6:13 UTC (permalink / raw)
  To: Matt Lee; +Cc: linux-usb

On Sun, Feb 09, 2025 at 11:06:42PM -0600, Matt Lee wrote:
> This patch series addresses two issues in the max3421 USB host controller
> driver:
> 
> 1. **Patch 1** This patch reverts the removal of the slow retransmit of NAK
> responses.  This fixes some USB accessories from becoming unresponsive.
> 
> 2. **Patch 2** fixes a "scheduling while atomic" bug in `max3421_remove()`
> by ensuring that `kthread_stop()` is called outside a spinlock, preventing
> a system crash when removing the driver or shutting down.
> 
> Both patches have been tested on a BCM2711 with MAX3421 hardware.
> 
> Kind regards,
> Matt Lee
> matt@oscium.com
> 
> ---
> 
> **Patches:**
> **[PATCH 1/2] USB: max3421: Fix retransmit handling for NAK responses**
> **[PATCH 2/2] USB: max3421: Fix scheduling while atomic in
> max3421_remove()**


Sorry, you can't attach patches, please send these as a proper patch
series.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-02-10  6:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-10  5:06 [PATCH 0/2] USB: max3421: Fix retransmit handling and scheduling while atomic Matt Lee
2025-02-10  6:13 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox