From: Ping-Ke Shih <pkshih@realtek.com>
To: "5mghybrid@khu.ac.kr" <5mghybrid@khu.ac.kr>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: Jes Sorensen <Jes.Sorensen@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH rtw-next v2 3/4] wifi: rtl8xxxu: preserve RX requests across recoverable transfer errors
Date: Thu, 17 Sep 2026 03:45:11 +0000 [thread overview]
Message-ID: <2b956e6e0c5945e596d5825ace0c6203@realtek.com> (raw)
In-Reply-To: <20260913-codex-rtw-rx-v2-v2-3-f09c964e0b96@khu.ac.kr>
kimwooseok via B4 Relay <devnull+5mghybrid.khu.ac.kr@kernel.org> wrote:
> From: kimwooseok <5mghybrid@khu.ac.kr>
>
> rtl8xxxu normally reuses 32 RX URBs, scheduling the submission worker when
> more than eight completed requests have accumulated on the pending list.
> Completion errors free URBs instead. A finite error burst can therefore
> leave eight or fewer requests, which cannot reach that threshold after
> they all complete. With no request in flight and no worker pending or
> running, RX stays stopped even after the errors cease.
>
> To prevent these errors from shrinking the pool below the number
> needed for normal resubmission, retain URBs after EPROTO, EILSEQ, ETIME,
> EOVERFLOW, ECOMM and ENOSR completions. EHCI can report ENOSR for
> IN data-buffer
> errors, and FHCI maps RX buffer overrun to ECOMM. Free the failed
> transfer's skb and keep its URB on a separate retry list.
>
> Keeping the URBs is only part of the fix: the driver must also submit
> them again without waiting for nine requests to accumulate. When the
> first failed request enters the retry list, schedule delayed work for
> 100 ms. Further failures join that list while the work is pending.
> When it runs, move the collected requests to normal pending and schedule
> the submission worker even if only one request is waiting. Keeping
> failed requests separate until then prevents normal completions from
> triggering an immediate retry; successful RX keeps its existing batching.
>
> A retry can itself fail with ENOMEM/EAGAIN. Returning that request to
> normal pending would bring back the same threshold problem, so route
> temporary submission failures from both start and the RX worker through
> the delayed retry list as well.
>
> Serialize retry insertion and scheduling with shutdown so late
> completions cannot schedule fresh retries during stop. Cancel retry work
> first, then wait for submission work before killing active URBs, so a
> running worker cannot submit a request after the active requests have
> been drained.
>
> Cancellation and removal keep their release behavior. EPIPE endpoint-halt
> recovery remains outside this change because it requires quiescing
> requests and distinguishing recovery cancellation from shutdown.
>
> Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
Same question. Is this patch strong enough to need a Fixes?
> Assisted-by: GPT-6 Astra
> Signed-off-by: kimwooseok <5mghybrid@khu.ac.kr>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/core.c | 71 ++++++++++++++++++++++--
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 3 +
> 2 files changed, 70 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> index 1932a9ec1970c..883c9a56f52a4 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
[...]
> +static void rtl8xxxu_rx_urb_retry_work(struct work_struct *work)
> +{
> + struct rtl8xxxu_priv *priv = container_of(to_delayed_work(work),
> + struct rtl8xxxu_priv,
> + rx_urb_retry_wq);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->rx_urb_lock, flags);
> +
> + if (!priv->shutdown && priv->rx_urb_retry_count) {
> + list_splice_tail_init(&priv->rx_urb_retry_list,
> + &priv->rx_urb_pending_list);
> + priv->rx_urb_pending_count += priv->rx_urb_retry_count;
> + priv->rx_urb_retry_count = 0;
> + /* An error must not leave a small batch waiting indefinitely. */
> + schedule_work(&priv->rx_urb_wq);
> + }
> +
> + spin_unlock_irqrestore(&priv->rx_urb_lock, flags);
> +}
> +
> +static void rtl8xxxu_queue_rx_urb_retry(struct rtl8xxxu_priv *priv,
> + struct rtl8xxxu_rx_urb *rx_urb)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->rx_urb_lock, flags);
> +
> + if (!priv->shutdown) {
> + list_add_tail(&rx_urb->list, &priv->rx_urb_retry_list);
> + priv->rx_urb_retry_count++;
> + /* Keep normal completions from bypassing the error backoff. */
> + queue_delayed_work(system_wq, &priv->rx_urb_retry_wq,
> + msecs_to_jiffies(RTL8XXXU_RX_URB_RETRY_DELAY_MS));
> + } else {
> + usb_free_urb(&rx_urb->urb);
> + }
> +
> + spin_unlock_irqrestore(&priv->rx_urb_lock, flags);
> +}
> +
These two are very similar to existing codes, and ...
> static void rtl8xxxu_rx_urb_work(struct work_struct *work)
> {
> struct rtl8xxxu_priv *priv;
[...]
> @@ -6618,7 +6665,20 @@ static void rtl8xxxu_rx_complete(struct urb *urb)
> rtl8xxxu_queue_rx_urb(priv, rx_urb);
> } else {
> dev_dbg(dev, "%s: status %i\n", __func__, urb->status);
> - goto cleanup;
> + switch (urb->status) {
> + case -EPROTO:
> + case -EILSEQ:
> + case -ETIME:
> + case -EOVERFLOW:
> + case -ECOMM:
> + case -ENOSR:
> + dev_kfree_skb(skb);
> + urb->context = NULL;
> + rtl8xxxu_queue_rx_urb_retry(priv, rx_urb);
Why can't it just call rtl8xxxu_queue_rx_urb()?
The key point is that you want an additional delay? If so, maybe we can
flag for these cases and reuse rtl8xxxu_queue_rx_urb().
> + return;
> + default:
> + goto cleanup;
> + }
> }
> return;
>
next prev parent reply other threads:[~2026-09-17 3:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 7:33 [PATCH rtw-next v2 0/4] wifi: rtl8xxxu: keep RX requests available across transient errors kimwooseok via B4 Relay
2026-09-13 7:33 ` [PATCH rtw-next v2 1/4] wifi: rtl8xxxu: free RX skb when URB submission fails kimwooseok via B4 Relay
2026-09-17 1:18 ` Ping-Ke Shih
2026-09-17 1:57 ` 김우석[학생](전자정보대학 전자공학과)
2026-09-17 7:31 ` 김우석[학생](전자정보대학 전자공학과)
2026-09-13 7:33 ` [PATCH rtw-next v2 2/4] wifi: rtl8xxxu: unwind incomplete receive startup kimwooseok via B4 Relay
2026-09-17 3:20 ` Ping-Ke Shih
2026-09-17 7:27 ` 김우석[학생](전자정보대학 전자공학과)
2026-09-13 7:33 ` [PATCH rtw-next v2 3/4] wifi: rtl8xxxu: preserve RX requests across recoverable transfer errors kimwooseok via B4 Relay
2026-09-17 3:45 ` Ping-Ke Shih [this message]
2026-09-17 7:29 ` 김우석[학생](전자정보대학 전자공학과)
2026-09-17 7:52 ` Ping-Ke Shih
2026-09-13 7:33 ` [PATCH rtw-next v2 4/4] wifi: rtl8xxxu: test RX ownership and recovery across failures kimwooseok via B4 Relay
2026-09-17 6:27 ` Ping-Ke Shih
2026-09-17 7:30 ` 김우석[학생](전자정보대학 전자공학과)
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=2b956e6e0c5945e596d5825ace0c6203@realtek.com \
--to=pkshih@realtek.com \
--cc=5mghybrid@khu.ac.kr \
--cc=Jes.Sorensen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®