linux-kernel - Re: [External] RE: [RFC -v1] wifi: rtw88: sdio: Tx status for management frames

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <b7651a17-afeb-4abd-ae23-29a85a2f6412@nokia-sbell.com>
Date: Tue, 8 Apr 2025 11:29:37 +0800
From: Zhen XIN <zhen.xin@...ia-sbell.com>
To: Ping-Ke Shih <pkshih@...ltek.com>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [External] RE: [RFC -v1] wifi: rtw88: sdio: Tx status for
 management frames


On 1/1/1970 8:00 AM, Ping-Ke Shih wrote:
> Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
>>>> @@ -1195,7 +1195,7 @@ static void rtw_sdio_indicate_tx_status(struct rtw_dev *rtwdev,
>>>>          skb_pull(skb, rtwdev->chip->tx_pkt_desc_sz);
>>>>
>>>>          /* enqueue to wait for tx report */
>>>> -       if (info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS) {
>>>> +       if (info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS && queue
>>>> + <= RTW_TX_QUEUE_VO) {
>>> Is this because you have seen "failed to get tx report"?
>>> Have you tried to increasing RTW_TX_PROBE_TIMEOUT?
>>>
>>> If it still can't get TX report, we might take this workaround with
>>> comments to mention why we need it. Or a local variable with proper
>>> naming to point out this, like
>>>
>>>          bool queue_has_no_tx_report = queue > RTW_TX_QUEUE_VO;
>>>
>>>
>>> By the way, USB behavior is very like to SDIO, but TX report seems to work well.
>> On my RTL8822CS I can confirm your thought:
>> I don't notice any extra "failed to get tx report" messages regardless
>> of whether I have "&& queue <= RTW_TX_QUEUE_VO" or not.
>>
> This workaround might need an chip attribute to enable then.
> Not sure if people in the GitHub thread have experiments on all supported SDIO WiFi chips.

On my RTL8723DS, without condition"&& queue <= RTW_TX_QUEUE_VO", there 
are messages in the console:

[ 23.298425] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware

Ever after I doubled the RTW_TX_PROBE_TIMEOUT (500 * 2), there messages 
were still there, and AP mode didn't work:

root@...nWrt:~# iw dev phy0-ap0 station dump Station 04:ea:56:2f:6f:07 
(on phy0-ap0) inactive time: 480 ms ... authorized: no authenticated: 
yes associated: yes

Seems tx status report didn't reach hostapd.