RE: [PATCH v7 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS

[Ping-Ke Shih <pkshih@realtek.com>]

Luka Gejak <luka.gejak@linux.dev> wrote:
> On August 25, 2026 10:22:53 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:
> 
> > But I don't find rtw_sdio_write_to_port()?
> 
> My fault, it does not exist in v7. It is a function I added in v8 while
> splitting the locked region out for guard(), and I asked you about it
> without saying that. Sorry for the confusion. In v8 the transfer moved
> into rtw_sdio_write_to_port(), called from both the generic path and the
> 8723BS one, and the warning had to go either inside it once or in both
> callers. That was the whole of my question.

Let's review it by v8. Please help to mention this by change log.

> 
> > Is this a normal case? Can current sdio.c handle this properly?
> > If so, I'd change to debug level.
> 
> It should never happen. rtw_sdio_tx_skb_prepare() aligns the pointer
> itself: it pushes the packet descriptor, and if the result is not aligned
> to RTW_SDIO_DATA_PTR_ALIGN it pushes the difference as padding and tells
> the firmware about the shifted offset. main.c reserves those 8 bytes in
> hw->extra_tx_headroom for SDIO so the push always has room. So by the time
> rtw_sdio_write_port() runs the pointer is aligned by construction, and the
> check is really an assertion that the alignment step did its job.
> 
> It has never fired here, across all the testing on this chip.
> 
> So I would keep it at warn rather than debug. If it ever does fire it means
> the alignment path above is broken, and the transfer would go out with a
> misaligned pointer, which is worth being loud about. But it is your code
> and your call.

Okay. 

By the way, I'm not so familiar with SDIO code. Just learn by reviewing. :)

Ping-Ke