mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;
> 


  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®