From: Luka Gejak <luka.gejak@linux.dev>
To: Ping-Ke Shih <pkshih@realtek.com>,
"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>,
luka.gejak@linux.dev
Subject: RE: [PATCH v7 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS
Date: Tue, 25 Aug 2026 09:20:47 +0200 [thread overview]
Message-ID: <AD323744-AE68-4C77-92A9-CD215B8A7E43@linux.dev> (raw)
In-Reply-To: <17c3c1f641fe41c4bfacb989af4b75a6@realtek.com>
Hi Ping-Ke,
On August 25, 2026 8:12:58 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:
> I think you only need to note 'not free the skb on failure'.
> And move comment here to note __skb_pad().
> By the way, we can have a local variable 'pad_size'.
Done, all three:
if (write_size > skb->len) {
size_t pad_size = write_size - skb->len;
/*
* __skb_pad() must not free the skb on failure: both callers
* still own it, one requeues it and the other frees it.
*/
ret = __skb_pad(skb, pad_size, false);
if (ret)
return ret;
}
> Not sure if the comment along declaration of tx_credit_lock is enough?
> If so, maybe we don't need this comment.
Agreed, that one is gone.
> guard(mutex)(&rtwsdio->tx_credit_lock);
The lock is only taken for this chip, and guard() is unconditional, so I
split the locked region into its own function instead of branching around
the lock:
if (!rtw_is_8723bs(rtwdev)) {
txsize = sdio_align_size(rtwsdio->sdio_func, skb->len);
ret = rtw_sdio_check_free_txpg(rtwdev, queue, txsize);
if (ret)
return ret;
return rtw_sdio_write_to_port(rtwdev, skb, queue, txaddr,
txsize);
}
...
guard(mutex)(&rtwsdio->tx_credit_lock);
return rtw_sdio_8723bs_write_port(rtwdev, skb, queue, txaddr, txsize,
write_size);
The transfer itself moved to rtw_sdio_write_to_port() so both paths share
it. That also removes the goto and the two rtl8723bs tests in the middle of
the function.
One thing I would like your opinion on while it is still cheap to change.
The unaligned SKB warning now sits in both callers rather than once inside
rtw_sdio_write_to_port(), because __func__ would otherwise report
rtw_sdio_write_to_port for every other SDIO chip where it reports
rtw_sdio_write_port today. Keeping that message identical costs three
duplicated lines. Putting it once in rtw_sdio_write_to_port() is the
tidier code and arguably the more accurate message, at the price of
changing a log line on chips this series is not about. I went with the
duplicate to leave the other parts alone, but I have no strong feeling
either way, so say which you prefer.
> I think you can add lockdep_assert_held() to the places the locks (mutex)
> must be held, and run test if somewhere throw warning (must not).
Added to rtw_sdio_8723bs_write_port(), rtw_sdio_8723bs_wait_tx_oqt() and
rtw_sdio_8723bs_consume_txpg(). Each has exactly one caller and all three
sit under the guard, so the call graph says they cannot be reached without
the lock.
I have to be straight about the test though: my test kernel is built
without CONFIG_PROVE_LOCKING, so those asserts compile to nothing there and
running it would prove nothing. I will build a kernel with lockdep enabled
and confirm before I would ask you to take the patch on that point, unless
you would rather I just drop the asserts.
Best regards,
Luka Gejak
next prev parent reply other threads:[~2026-08-25 7:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 9:04 [PATCH v7 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-08-20 9:04 ` [PATCH v7 1/6] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-08-20 9:04 ` [PATCH v7 2/6] wifi: rtw88: rx: mark zero length packets on RTL8723BS luka.gejak
2026-08-20 9:04 ` [PATCH v7 3/6] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-08-20 9:04 ` [PATCH v7 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-08-25 6:12 ` Ping-Ke Shih
2026-08-25 7:20 ` Luka Gejak [this message]
2026-08-25 7:25 ` Ping-Ke Shih
2026-08-25 7:33 ` Luka Gejak
2026-08-25 7:50 ` Ping-Ke Shih
2026-08-25 8:07 ` Luka Gejak
2026-08-25 8:22 ` Ping-Ke Shih
2026-08-25 8:32 ` Luka Gejak
2026-08-25 8:38 ` Ping-Ke Shih
2026-08-25 8:42 ` Luka Gejak
2026-08-25 8:49 ` Ping-Ke Shih
2026-08-20 9:04 ` [PATCH v7 5/6] wifi: rtw88: sdio: set up RX aggregation and interrupts " luka.gejak
2026-08-20 9:04 ` [PATCH v7 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation luka.gejak
2026-08-25 6:36 ` Ping-Ke Shih
2026-08-25 7:22 ` Luka Gejak
2026-08-25 8:27 ` Ping-Ke Shih
2026-08-22 16:51 ` [PATCH v7 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS Luka Gejak
2026-08-23 6:00 ` Luka Gejak
2026-08-25 7:08 ` Ping-Ke Shih
2026-08-25 7:27 ` 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=AD323744-AE68-4C77-92A9-CD215B8A7E43@linux.dev \
--to=luka.gejak@linux.dev \
--cc=johannes.goede@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pbrobinson@gmail.com \
--cc=pkshih@realtek.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
all inboxes | Powered by JetHome®