Re: [PATCH v8 0/2] staging: rtl8723bs: Fix error handling in _rtw_pktfile_read()

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Fri, Jun 05, 2026 at 12:47:59AM +0300, Bitterblue Smith wrote:
> On 03/06/2026 17:06, Andy Shevchenko wrote:
> > On Wed, Jun 03, 2026 at 04:40:45PM +0300, Bitterblue Smith wrote:
> >> On 03/06/2026 03:48, Andy Shevchenko wrote:
> >>> On Sun, May 24, 2026 at 09:30:01PM +0300, Bitterblue Smith wrote:
> >>>> On 27/01/2026 17:38, Minu Jin wrote:
> >>>>> This series improves error handling in _rtw_pktfile_read() and cleans up
> >>>>> the code style to comply with kernel standards.
> >>>>>
> >>>>> 1. The first patch combines the logic change and caller updates.
> >>>>>    The function change and the caller updates must be in the same
> >>>>>    patch. If they are separated, the code will not work correctly 
> >>>>>    or will cause errors at that specific point in the history.
> >>>>>
> >>>>> 2. The second patch focuses purely on code style cleanup (changing uint
> >>>>>    to unsigned int) as requested by Andy Shevchenko.
> >>>>>
> >>>>> Regarding the logic change in _rtw_pktfile_read():
> >>>>>
> >>>>>     The original code used a ternary operator to read whatever data was 
> >>>>>     available, even if it was less than requested. This could lead to 
> >>>>>     callers processing incomplete data without knowing it.
> >>>>>
> >>>>>     I have changed this to return -EINVAL when the remaining data is insufficient. 
> >>>>>     This is safer because most callers expect the exact amount of data and 
> >>>>>     should not proceed with a partial read.
> >>>>>
> >>>>> Testing and Verification:
> >>>>>
> >>>>>     I do not have access to the physical RTL8723BS hardware. However, I have
> >>>>>     performed a rigorous manual audit of the data path and verified the
> >>>>>     changes using Smatch static analysis. The analysis confirmed that no
> >>>>>     new warnings or logical regressions were introduced in the modified files.
> >>>>
> >>>> I have some bad news:
> >>>>
> >>>> https://bbs.archlinux.org/viewtopic.php?id=313401
> >>>
> >>> It's unclear that this patch made it happen. See below.
> >>
> >> It looks pretty clear to me, but okay. I forwarded your request for bisection.
> > 
> > I don't know how it does. There is no information about from which kernel one
> > upgrades to which. I assumed someone bumps from v7.0 to v7.0.3, but there no
> > such patch. If we take v6.19..v7.0.3 range, there are dozens of patches.
> > 
> > I.o.w. it is semi-poorly written bug report: some of useful information and
> > some crucial that is missing...
> > 
> 
> The new message "coalesce failed with error -22" is printed when
> rtw_xmitframe_coalesce() returns -EINVAL. This is the only recent patch
> which touched rtw_xmitframe_coalesce().

Fair enough.
The quick fix is to replace

		return -EINVAL;

with

		rlen = rtw_remainder_len(pfile);

in drivers/staging/rtl8723bs/os_dep/xmit_linux.c::_rtw_pktfile_read().

There might be a better fix to understand why the requested length in that case
is bigger than remainder in the device.

> >>>> [quote]
> >>>>
> >>>> I recently upgraded my system, and now I’m having a strange issue with my
> >>>> WiFi (Realtek RTL8723BS).
> >>>>
> >>>> now I can no longer connect to any WiFi networks as a client. however,
> >>>> creating an Access Point (AP) still works fine, but whenever I try to connect
> >>>> to an existing network, the connection fails.
> >>>>
> >>>> dmesg logs:
> >>>> Every time I attempt a connection, dmesg gets spammed with this error:
> >>>>
> >>>>     [ 1083.925640] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >>>>     [ 1084.921217] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >>>>     [ 1085.921434] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >>>>     [ 1086.922320] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >>>>     ....
> >>>>
> >>>> Has anyone encountered this specific "coalesce" error with the rtl8723bs
> >>>> driver? I'm looking for advice on whether this is a known bug in recent
> >>>> kernels or if there's a specific module parameter I should try to bypass
> >>>> this.
> >>>>
> >>>> System Info:
> >>>>
> >>>>     Chipset: RTL8723BS (SDIO)
> >>>>
> >>>>     Kernel version: 7.0.3-zen1-2-zen
> >>>>
> >>>> update: I fixed the issue after kernel downgrade
> >>>>
> >>>> [/quote]
> >>>
> >>> That guy should bisect and find the culprit. It will help a lot to understand
> >>> what's going on.

-- 
With Best Regards,
Andy Shevchenko