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

[Bitterblue Smith]

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().

>>>> [quote]
>>>>
>>>> Hey everyone,
>>>>
>>>> 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.
>