All of lore.kernel.org
 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 v9 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS
Date: Wed, 9 Sep 2026 05:36:42 +0000	[thread overview]
Message-ID: <6a59823f69d140b1a6c44d475f5b93bd@realtek.com> (raw)
In-Reply-To: <DL9Y9KGJKWIT.26GHPWWWG0WFV@linux.dev>


Luka Gejak <luka.gejak@linux.dev> wrote:
> On Sun Sep 6, 2026 at 4:22 AM CEST, Ping-Ke Shih wrote:
> [...]
> > If the __skb_padd() is necessary for original (generic) part, please
> > add another patch to fix it. (see below comment)
> [...]
> > Why doesn't rtw_sdio_write_port_generic() need __skb_pad() as well?
> > Is there an existing problem by original?
> 
> There is. rtw_sdio_write_port() rounds the transfer up with
> sdio_align_size() and passes that length to sdio_memcpy_toio() while the
> skb still holds only skb->len bytes, so between one and 511 bytes from
> past the end of the frame get transmitted. Whether that stays inside the
> skb's allocation depends on how much tailroom it happens to have.
> 
> It gets its own patch, no chip condition:
> 
>   wifi: rtw88: sdio: zero the padding added to a TX transfer

Will/should you add this in v10 or v11 before your patch 4/6?

As your v10 didn't get ran by NIPA because of [1], you can send v10 with
RESEND or just send v11 (including the additional one).

(To answer the ordering point question below.) I prefer to have the patch
in advance, for two reasons. One is to backport easier, and another is to
clear to know it is existing problem.

[1] https://lore.kernel.org/linux-wireless/fe0d8a3c2951c051b321902582eaf95f230a754d.camel@sipsolutions.net/T/#u

> 
> > As we have sdio_set_block_size(sdio_func, RTW_SDIO_BLOCK_SIZE),
> > can here use sdio_align_size() to get the writ_size?
> 
> Yes, and v10 does. I checked it is really the same rather than only
> looking the same: on this card sdio_align_size() matches the open coded
> rounding at the block boundaries, and over a full session it agreed on
> every frame, 80000 of them with no difference.
> 
> It is equivalent because the card reports multi block support and a 512
> byte block size, which puts the byte mode limit at 512. Without those
> two properties sdio_align_size() falls into chunked byte transfers that
> are not block multiples, so the equivalence is a property of this card
> and host rather than something unconditional. It is still the right call:
> it is the core helper and it is what the generic path already uses.

In v10, the beginning of rtw_sdio_write_port_8723bs() and
rtw_sdio_write_port_generic become the similar. And
I think ' txsize = round_up(skb->len, 4);' is not necessary to
rtw_sdio_write_port_8723bs() because it is 512-byte aligned.

Therefore, you can do the same thing in rtw_sdio_write_port() and then
call 
    rtw_sdio_write_port_8723bs()
or
    rtw_sdio_write_port_generic()
by condition. 

> 
> > I think write_size must be large or equal to skb->len, right?
> > Therefore, declare size_t pad_size at top of function, and then
> [...]
> > I think this is easier to read.
> 
> You are right that it can never be negative. The whole block is gone in
> v10 with the padding, so the question does not arise any more, but it
> would have been the better shape.

Will this be needed by the additional patch

   "wifi: rtw88: sdio: zero the padding added to a TX transfer"?

> 
> > In this patchset, you add many comments. Please review them across whole
> > patchset to see if they actually need. Like this one, do you think the code
> > can't explain itself?
> 
> I went through the series and removed redundant comments: v10 adds 62 comment
> lines where v9 added 103.
> 
> What I kept is the things the code cannot show: which page pool a queue
> draws from and how that was measured on hardware, why the counters are
> atomic_t, why only the defined interrupt status bits are acknowledged,
> and the two places where an skb has already been handed on and must not
> be touched. Two more are there because they were asked for in earlier
> review: the comment in patch 2 and the mod_delayed_work() one in patch 6.
> Say the word if any of those should go too.

I will check this by v11, because I'd like you can have v11 with

  1. "wifi: rtw88: sdio: zero the padding added to a TX transfer"
  2. move the same beginning of rtw_sdio_write_port_8723bs()
     and rtw_sdio_write_port_generic() to rtw_sdio_write_port()

Is it okay to you?

Ping-Ke


  reply	other threads:[~2026-09-09  5:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  6:11 [PATCH v9 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-08-31  6:11 ` [PATCH v9 1/6] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-08-31  6:11 ` [PATCH v9 2/6] wifi: rtw88: rx: mark zero length packets on RTL8723BS luka.gejak
2026-08-31  6:11 ` [PATCH v9 3/6] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-08-31  6:11 ` [PATCH v9 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-09-06  2:22   ` Ping-Ke Shih
2026-09-08 12:56     ` Luka Gejak
2026-09-09  5:36       ` Ping-Ke Shih [this message]
2026-09-09  8:04         ` Luka Gejak
2026-08-31  6:11 ` [PATCH v9 5/6] wifi: rtw88: sdio: set up RX aggregation and interrupts " luka.gejak
2026-08-31  6:11 ` [PATCH v9 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation 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=6a59823f69d140b1a6c44d475f5b93bd@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 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.