The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Luka Gejak <luka.gejak@linux.dev>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Michael Straube" <straube.linux@gmail.com>,
	Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	Peter Robinson <pbrobinson@gmail.com>,
	"Hans de Goede" <johannes.goede@oss.qualcomm.com>
Subject: RE: [PATCH v5 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation
Date: Wed, 19 Aug 2026 07:31:12 +0000	[thread overview]
Message-ID: <459e54292cf245e2ae6fd1a46afb6ec7@realtek.com> (raw)
In-Reply-To: <20260819071932.19596-1-luka.gejak@linux.dev>

Luka Gejak <luka.gejak@linux.dev> wrote:
> > I'd move this chunk you are adding to a function.
> 
> Done. The conditions now live in rtw_sdio_8723bs_reschedule_tx(), which
> decides whether the work should run again and says why, so the handler
> loop is just:
> 
>         ret = rtw_sdio_process_tx_queue(rtwdev, queue);
>         if (ret > 0)
>                 break;
> 
>         if (rtw_sdio_8723bs_reschedule_tx(rtwdev, work_data, queue, ret))
>                 return;
> 
>         if (skb_queue_empty(&rtwsdio->tx_queue[queue]))
>                 break;

It looks much better. :)

> 
> While rewriting that I found something I had got wrong in v4 and v5, and
> it is worth pointing out because it was not limited to this chip. Both
> versions had an unconditional
> 
>         if (ret < 0)
>                 break;

I didn't get this point. I'll review carefully on this part in v6.

> 
> in that loop. Upstream requeues the frame on a failed transfer and lets
> the loop retry, so that break quietly changed every other SDIO part to
> give up after the first failure. That contradicted the scope claim in my
> own cover letter. It is dropped in v6: the two errors this chip needs to
> retry are handled in the helper before that point, and everything else
> keeps the existing behaviour, so the other parts are untouched again.

Thanks for pointing this. 

If you have another SDIO chip, such as RTL8723CS, please verify your patches
on another real hardware, because it is not possible to catch all flaws by
reviewer (like me). Using real hardware with a simple throughput test is more
important.

Ping-Ke


  reply	other threads:[~2026-08-19  7:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 10:53 [PATCH v5 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-08-14 10:53 ` [PATCH v5 1/6] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-08-14 10:53 ` [PATCH v5 2/6] wifi: rtw88: rx: mark zero length packets on RTL8723BS luka.gejak
2026-08-19  0:41   ` Ping-Ke Shih
2026-08-14 10:53 ` [PATCH v5 3/6] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-08-14 10:53 ` [PATCH v5 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-08-19  0:52   ` Ping-Ke Shih
2026-08-14 10:53 ` [PATCH v5 5/6] wifi: rtw88: sdio: set up RX aggregation and interrupts " luka.gejak
2026-08-19  0:56   ` Ping-Ke Shih
2026-08-14 10:53 ` [PATCH v5 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation luka.gejak
2026-08-19  1:14   ` Ping-Ke Shih
2026-08-19  7:19     ` Luka Gejak
2026-08-19  7:31       ` Ping-Ke Shih [this message]
2026-08-19  9:17         ` Luka Gejak
2026-08-19  0:44 ` [PATCH v5 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS Ping-Ke Shih
2026-08-19  7:19   ` [PATCH v5 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS support Luka Gejak

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=459e54292cf245e2ae6fd1a46afb6ec7@realtek.com \
    --to=pkshih@realtek.com \
    --cc=johannes.goede@oss.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luka.gejak@linux.dev \
    --cc=pbrobinson@gmail.com \
    --cc=rtl8821cerfe2@gmail.com \
    --cc=straube.linux@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox