From: Greg KH <gregkh@linuxfoundation.org>
To: Matt Lee <matt@oscium.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/2] USB: max3421: Improve retransmit handling for NAK responses
Date: Mon, 10 Feb 2025 15:05:52 +0100 [thread overview]
Message-ID: <2025021054-rush-endocrine-c5f7@gregkh> (raw)
In-Reply-To: <CABrMTjey9pZXh=fWevfv2saNOs+_2uV6feV5xbYbP_4nKcq8mw@mail.gmail.com>
On Mon, Feb 10, 2025 at 07:57:20AM -0600, Matt Lee wrote:
> This reverts a previously submitted patch where the slow retransmit was removed.
What is that git commit id you are reverting? Please list it and mark
the Fixes: and cc: stable tag as needed.
>
> Previously, the max3421 driver would immediately retry transmissions
> indefinitely
> upon receiving a NAK response, leading to potential stalls.
Odd line-wrapping :(
>
> 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);
Did you run scripts/checkpatch.pl on this change?
And why is 2 ok? How did that number get picked?
thanks,
greg k-h
next prev parent reply other threads:[~2025-02-10 14:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 13:57 [PATCH 1/2] USB: max3421: Improve retransmit handling for NAK responses Matt Lee
2025-02-10 14:05 ` Greg KH [this message]
[not found] <CABrMTjempFXxCt4FhZPVUo=4h+o1hxoppoOmbfcbD-yGLt==Xg@mail.gmail.com>
2025-02-10 14:06 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025021054-rush-endocrine-c5f7@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=matt@oscium.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.