* [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY
From: Richard Acayan @ 2026-02-10 2:12 UTC (permalink / raw)
To: Jeff Johnson, Michal Kazior, Kalle Valo, linux-wireless, ath10k
Cc: Richard Acayan
In-Reply-To: <20260210021249.12132-1-mailingradian@gmail.com>
When sending DELETE_KEY, the driver times out waiting for a response
that doesn't come. Only wait for a response when sending SET_KEY.
Sample dmesg:
[ 117.285854] wlan0: deauthenticating from XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING)
[ 120.302934] ath10k_snoc 18800000.wifi: failed to install key for vdev 0 peer XX:XX:XX:XX:XX:XX: -110
[ 120.302996] wlan0: failed to remove key (0, XX:XX:XX:XX:XX:XX) from hardware (-110)
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index da6f7957a0ae..73aa93043f8a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -324,9 +324,11 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
if (ret)
return ret;
- time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
- if (time_left == 0)
- return -ETIMEDOUT;
+ if (cmd != DISABLE_KEY) {
+ time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
+ if (time_left == 0)
+ return -ETIMEDOUT;
+ }
return 0;
}
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 1/2] wifi: ath10k: make in-order rx amsdu buffers persistent
From: Richard Acayan @ 2026-02-10 2:12 UTC (permalink / raw)
To: Jeff Johnson, Michal Kazior, Kalle Valo, linux-wireless, ath10k
Cc: Richard Acayan
In-Reply-To: <20260210021249.12132-1-mailingradian@gmail.com>
The WCN3990 might split MSDUs among multiple "in-order" indications. The
driver needs information from previous indications to handle MPDUs that
are not started by the same indications that complete them. Move the
list that tracks unprocessed MSDUs to the driver state so the driver can
handle MPDUs that are split in this way and be less confused.
Fixes: c545070e404b ("ath10k: implement rx reorder support")
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
drivers/net/wireless/ath/ath10k/htt.h | 4 +++
drivers/net/wireless/ath/ath10k/htt_rx.c | 41 ++++++++++++++++++------
2 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 603f6de62b0a..ec897175c933 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1929,6 +1929,10 @@ struct ath10k_htt {
bool bundle_tx;
struct sk_buff_head tx_req_head;
struct sk_buff_head tx_complete_head;
+
+ u8 rx_in_ord_split_tid;
+ u16 rx_in_ord_split_peer_id;
+ struct sk_buff_head rx_in_ord_split;
};
struct ath10k_htt_tx_ops {
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index d7e429041065..b27271c56d07 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -297,6 +297,8 @@ void ath10k_htt_rx_free(struct ath10k_htt *htt)
skb_queue_purge(&htt->rx_in_ord_compl_q);
skb_queue_purge(&htt->tx_fetch_ind_q);
+ skb_queue_purge(&htt->rx_in_ord_split);
+
spin_lock_bh(&htt->rx_ring.lock);
ath10k_htt_rx_ring_free(htt);
spin_unlock_bh(&htt->rx_ring.lock);
@@ -846,6 +848,8 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
skb_queue_head_init(&htt->tx_fetch_ind_q);
atomic_set(&htt->num_mpdus_ready, 0);
+ skb_queue_head_init(&htt->rx_in_ord_split);
+
ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt rx ring size %d fill_level %d\n",
htt->rx_ring.size, htt->rx_ring.fill_level);
return 0;
@@ -3264,7 +3268,6 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
struct ath10k_htt *htt = &ar->htt;
struct htt_resp *resp = (void *)skb->data;
struct ieee80211_rx_status *status = &htt->rx_status;
- struct sk_buff_head list;
struct sk_buff_head amsdu;
u16 peer_id;
u16 msdu_count;
@@ -3299,16 +3302,32 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
return -EINVAL;
}
+ if (!skb_queue_empty(&htt->rx_in_ord_split)) {
+ /* It might still be possible to handle this case if there is
+ * only one peer that splits at each given moment. We are
+ * bailing out because we should have a test case for this
+ * before trying to fix it.
+ */
+ if (tid != htt->rx_in_ord_split_tid
+ || peer_id != htt->rx_in_ord_split_peer_id
+ || offload) {
+ ath10k_warn(ar, "split amsdu did not resume immediately\n");
+ htt->rx_confused = true;
+ return -EIO;
+ }
+ }
+
/* The event can deliver more than 1 A-MSDU. Each A-MSDU is later
* extracted and processed.
+ *
+ * It can also continue a previous A-MSDU.
*/
- __skb_queue_head_init(&list);
if (ar->hw_params.target_64bit)
ret = ath10k_htt_rx_pop_paddr64_list(htt, &resp->rx_in_ord_ind,
- &list);
+ &htt->rx_in_ord_split);
else
ret = ath10k_htt_rx_pop_paddr32_list(htt, &resp->rx_in_ord_ind,
- &list);
+ &htt->rx_in_ord_split);
if (ret < 0) {
ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
@@ -3320,11 +3339,12 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
* separately.
*/
if (offload)
- ath10k_htt_rx_h_rx_offload(ar, &list);
+ ath10k_htt_rx_h_rx_offload(ar, &htt->rx_in_ord_split);
- while (!skb_queue_empty(&list)) {
+ while (!skb_queue_empty(&htt->rx_in_ord_split)) {
__skb_queue_head_init(&amsdu);
- ret = ath10k_htt_rx_extract_amsdu(&ar->hw_params, &list, &amsdu);
+ ret = ath10k_htt_rx_extract_amsdu(&ar->hw_params,
+ &htt->rx_in_ord_split, &amsdu);
switch (ret) {
case 0:
/* Note: The in-order indication may report interleaved
@@ -3340,12 +3360,15 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
ath10k_htt_rx_h_enqueue(ar, &amsdu, status);
break;
case -EAGAIN:
- fallthrough;
+ htt->rx_in_ord_split_tid = tid;
+ htt->rx_in_ord_split_peer_id = peer_id;
+
+ return -EIO;
default:
/* Should not happen. */
ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
htt->rx_confused = true;
- __skb_queue_purge(&list);
+ __skb_queue_purge(&htt->rx_in_ord_split);
return -EIO;
}
}
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 0/2] ath10k wifi fixes
From: Richard Acayan @ 2026-02-10 2:12 UTC (permalink / raw)
To: Jeff Johnson, Michal Kazior, Kalle Valo, linux-wireless, ath10k
Cc: Richard Acayan
These are WiFi fixes that seem to be helpful on SDM670. There is no
ath10k support for SDM670, but some similar SoCs also need these fixes.
This is RFC because there could be better solutions.
On SDM670 with patches, the MPDU has 32 MSDUs when the last one isn't
the last in the A-MSDU.
Richard Acayan (2):
wifi: ath10k: make in-order rx amsdu buffers persistent
wifi: ath10k: only wait for response to SET_KEY
drivers/net/wireless/ath/ath10k/htt.h | 4 +++
drivers/net/wireless/ath/ath10k/htt_rx.c | 41 ++++++++++++++++++------
drivers/net/wireless/ath/ath10k/mac.c | 8 +++--
3 files changed, 41 insertions(+), 12 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: New warning `ath10k_pci 0000:3a:00.0: not found station for peer stats`
From: Paul Menzel @ 2026-02-09 22:31 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson; +Cc: linux-wireless, ath10k
In-Reply-To: <5c152304-853d-4142-8553-55cd8907f271@oss.qualcomm.com>
Dear Baochen,
Am 09.02.26 um 03:44 schrieb Baochen Qiang:
> On 2/7/2026 1:55 PM, Paul Menzel wrote:
>> Am 19.01.26 um 17:41 schrieb Paul Menzel:
>>
>>> Since January 10th, I have started seeing the warning below in
>>> my Linux logs, that reach back to September 24th, 2025:
>>>
>>> [ 37.108902] ath10k_pci 0000:3a:00.0: not found station for peer stats
>>> [ 37.108906] ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22
>>>
>>> It started appearing with 6.19.0-rc4-00282-gb6151c4e60e5, the
>>> version running before is 6.19.0-rc4-00003-g3609fa95fb0f, but I
>>> do not see anything related in the commit list:>>>
>>> git log --oneline 3609fa95fb0f...b6151c4e60e5
>>>
>>> The warning log from `drivers/net/wireless/ath/ath10k/wmi-tlv.c` has also been there
>>> since 2021.
>>>
>>> Do you have an idea? Please find the output of `dmesg` attached.
>>
>> Looking through the commit list from above again, commit
>> a203dbeeca15 (wifi: mac80211: collect station statistics earlier
>> when disconnect) probably introduced the new behavior.
>
> is this error seen when disconnecting from AP?
I attached the logs in my first message. But yes, it looks like this:
Feb 07 06:32:52 abreu kernel: wlp58s0: deauthenticating from
74:1a:e0:e7:b4:c8 by local choice (Reason: 3=DEAUTH_LEAVING)
Feb 07 06:32:52 abreu kernel: ath10k_pci 0000:3a:00.0: not found
station for peer stats
Feb 07 06:32:52 abreu kernel: ath10k_pci 0000:3a:00.0: failed to
parse stats info tlv: -22
Feb 07 06:32:52 abreu wpa_supplicant[846]: wlp58s0:
CTRL-EVENT-DISCONNECTED bssid=74:1a:e0:e7:b4:c8 reason=3 locally_generated=1
Feb 07 06:32:52 abreu wpa_supplicant[846]: BSSID 74:1a:e0:e7:b4:c8
ignore list count incremented to 2, ignoring for 10 seconds
> did you try with that commit reverted?
Yes, I tried it now with Linux 6.19 and reverting the commit. The
warnings are gone now.
Are you able to reproduce the issue? What devices are you testing with?
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH v2][next] iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warnings
From: Gustavo A. R. Silva @ 2026-02-09 7:22 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, Stanislaw Gruszka, Johannes Berg,
linux-wireless, linux-kernel, linux-hardening
In-Reply-To: <202602091416.A7FD08F6C@keescook>
On 2/10/26 07:20, Kees Cook wrote:
> On Mon, Feb 09, 2026 at 03:23:59PM +0900, Gustavo A. R. Silva wrote:
>> Ah yes, I can do this. The only thing is that I'd have to change every
>> place where members in struct il4965_tx_resp are used, e.g.
>>
>> s/frame_count/hdr.frame_count
>
> Hm? No, that's what transparent struct members avoid: there is no
> sub-struct name, the members of the struct are transparently visible in
> the surrounding struct:
Ah yes, that's why it's defined like
+struct il4965_tx_resp {
+ struct il4965_tx_resp_hdr;
/*
* For non-agg: frame status TX_STATUS_*
@@ -2664,7 +2668,8 @@ struct il3945_beacon_notif {
} __packed;
and not like
+struct il4965_tx_resp {
+ struct il4965_tx_resp_hdr hdr;
/*
* For non-agg: frame status TX_STATUS_*
@@ -2664,7 +2668,8 @@ struct il3945_beacon_notif {
} __packed;
>
> struct inside {
> int a;
> int b;
> };
>
> struct foo {
> struct inside;
> int c;
> } *p;
>
> "p->a" is valid.
Yes, gotcha!
>
>> Another thing to take into account (fortunately, not in this case) is
>> when the FAM needs to be annotated with __counted_by(). If we use a
>> separate struct for the header portion of the flexible structure, GCC
>> currently cannot _see_ the _counter_ if it's included in a non-anonymous
>> structure. However, this will be possible in the near future, correct?
>
> Right, that's still in progress. I don't expect it soon, though. :(
>
Okay.
-Gustavo
^ permalink raw reply
* Re: [PATCH v2][next] iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warnings
From: Kees Cook @ 2026-02-09 22:20 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Gustavo A. R. Silva, Stanislaw Gruszka, Johannes Berg,
linux-wireless, linux-kernel, linux-hardening
In-Reply-To: <4bf43164-b130-4643-9f4f-761f49bd0dc9@embeddedor.com>
On Mon, Feb 09, 2026 at 03:23:59PM +0900, Gustavo A. R. Silva wrote:
> Ah yes, I can do this. The only thing is that I'd have to change every
> place where members in struct il4965_tx_resp are used, e.g.
>
> s/frame_count/hdr.frame_count
Hm? No, that's what transparent struct members avoid: there is no
sub-struct name, the members of the struct are transparently visible in
the surrounding struct:
struct inside {
int a;
int b;
};
struct foo {
struct inside;
int c;
} *p;
"p->a" is valid.
> Another thing to take into account (fortunately, not in this case) is
> when the FAM needs to be annotated with __counted_by(). If we use a
> separate struct for the header portion of the flexible structure, GCC
> currently cannot _see_ the _counter_ if it's included in a non-anonymous
> structure. However, this will be possible in the near future, correct?
Right, that's still in progress. I don't expect it soon, though. :(
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2][next] iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warnings
From: Gustavo A. R. Silva @ 2026-02-09 6:23 UTC (permalink / raw)
To: Kees Cook, Gustavo A. R. Silva
Cc: Stanislaw Gruszka, Johannes Berg, linux-wireless, linux-kernel,
linux-hardening
In-Reply-To: <202602091212.743C6B9B7C@keescook>
On 2/10/26 05:46, Kees Cook wrote:
> On Mon, Feb 09, 2026 at 01:38:15PM +0900, Gustavo A. R. Silva wrote:
>> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
>> getting ready to enable it, globally.
>>
>> Move the conflicting declarations (which in a couple of cases happen
>> to be in a union, so the entire unions are moved) to the end of the
>> corresponding structures. Notice that `struct il_tx_beacon_cmd`,
>> `struct il4965_tx_resp`, and `struct il3945_tx_beacon_cmd` are flexible
>> structures, this is structures that contain a flexible-array member.
>
> I think explicit mention of il3945_frame and il_frame should be included
> in the commit log (probably after the above), as they are the ones that
> contain the mentioned il*_tx_beacon_cmd structs that have a trailing
> flex array.
Okay.
>
>> The case for struct il4965_beacon_notif is different. Since this
>> structure is defined by hardware, we use the struct_group() helper
>> to create the new `struct il4965_tx_resp_hdr` type. We then use this newly
>> created type to replace the obhect type of causing trouble in
>> struct il4965_beacon_notif, namely `stryct il4965_tx_resp`.
>
> Above two lines have typos and maybe a missing name (between "of" and
> "causing")?
Aggh.. yes, I had fixed this before, but somehow I ended up using the
wrong changelog text. Thanks for the catch!
>
>> In order to preserve the memory layout in struct il4965_beacon_notif,
>> add member `__le32 beacon_tx_status`, which was previously included
>> by `struct il4965_tx_resp` (as `__le32 status`), but it's not present
>> in the newly created type `struct il4965_tx_resp_hdr`.
>
> It may help to explicitly mention how the union exists to provide the
> "status" member to anything using struct il4965_tx_resp, but there's no
> sane way to do the overlap across structs, so anything using
> il4965_beacon_notif needs have its own view of "status".
Okay.
>
> It does feel like accessing il4965_tx_resp's agg_status should be using
> a different struct (like happens for other things that want bytes beyond
> "status"), but okay.
>
> Anyway, it's another situation of a header with a trailing flex array
> that needs to overlap with differing deserializations of the trailing
> bytes. The complication here is the kind of "layering violation" of
> agg_status and status.
>
>> Notice that after this changes, the size of struct il4965_beacon_notif
>> along with its member's offsets remain the same, hence the memory
>> layout doesn't change:
>>
>> Before changes:
>> struct il4965_beacon_notif {
>> struct il4965_tx_resp beacon_notify_hdr; /* 0 24 */
>> __le32 low_tsf; /* 24 4 */
>> __le32 high_tsf; /* 28 4 */
>> __le32 ibss_mgr_status; /* 32 4 */
>>
>> /* size: 36, cachelines: 1, members: 4 */
>> /* last cacheline: 36 bytes */
>> };
>>
>> After changes:
>> struct il4965_beacon_notif {
>> struct il4965_tx_resp_hdr beacon_notify_hdr; /* 0 20 */
>> __le32 beacon_tx_status; /* 20 4 */
>> __le32 low_tsf; /* 24 4 */
>> __le32 high_tsf; /* 28 4 */
>> __le32 ibss_mgr_status; /* 32 4 */
>>
>> /* size: 36, cachelines: 1, members: 5 */
>> /* last cacheline: 36 bytes */
>> };
>>
>> We also want to ensure that when new members are added to the flexible
>> structure `struct il4965_tx_resp` (if any), they are always included
>> within the newly created struct type. To enforce this, we use
>> `static_assert()` (which is intentionally placed right after the struct,
>> this is, no blank line in between). This ensures that the memory layout
>> of both the flexible structure and the new `struct il4965_tx_resp_hdr`
>> type remains consistent after any changes.
>>
>> Lastly, refactor the rest of the code, accordingly.
>
> I think the changes look consistent with other similar logical changes
> that have been made for -Wfamnae.
>
> Since enabling -fms-extensions I'm on the look-out for cases where
> we can use transparent struct members (i.e. define the header struct
> separately and then use it transparently) instead of using the struct
> group when we don't need to make the interior explicitly addressable
> (as we have in this case), as it makes the diff way smaller:
Ah yes, I can do this. The only thing is that I'd have to change every
place where members in struct il4965_tx_resp are used, e.g.
s/frame_count/hdr.frame_count
and so on...
Another thing to take into account (fortunately, not in this case) is
when the FAM needs to be annotated with __counted_by(). If we use a
separate struct for the header portion of the flexible structure, GCC
currently cannot _see_ the _counter_ if it's included in a non-anonymous
structure. However, this will be possible in the near future, correct?
>
> diff --git a/drivers/net/wireless/intel/iwlegacy/commands.h b/drivers/net/wireless/intel/iwlegacy/commands.h
> index b61b8f377702..440dff2a4ad9 100644
> --- a/drivers/net/wireless/intel/iwlegacy/commands.h
> +++ b/drivers/net/wireless/intel/iwlegacy/commands.h
> @@ -1690,7 +1690,7 @@ struct agg_tx_status {
> __le16 sequence;
> } __packed;
>
> -struct il4965_tx_resp {
> +struct il4965_tx_resp_hdr {
> u8 frame_count; /* 1 no aggregation, >1 aggregation */
> u8 bt_kill_count; /* # blocked by bluetooth (unused for agg) */
> u8 failure_rts; /* # failures due to unsuccessful RTS */
> @@ -1707,6 +1707,10 @@ struct il4965_tx_resp {
> __le16 reserved;
> __le32 pa_power1; /* RF power amplifier measurement (not used) */
> __le32 pa_power2;
> +} __packed;
> +
> +struct il4965_tx_resp {
> + struct il4965_tx_resp_hdr;
>
> /*
> * For non-agg: frame status TX_STATUS_*
> @@ -2664,7 +2668,8 @@ struct il3945_beacon_notif {
> } __packed;
>
> struct il4965_beacon_notif {
> - struct il4965_tx_resp beacon_notify_hdr;
> + struct il4965_tx_resp_hdr beacon_notify_hdr;
> + __le32 status;
> __le32 low_tsf;
> __le32 high_tsf;
> __le32 ibss_mgr_status;
>
>
> What do folks think?
I'll wait for maintainers to chime in.
>
>> With these changes fix the following warnings:
>>
>> 11 drivers/net/wireless/intel/iwlegacy/common.h:526:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
>> 11 drivers/net/wireless/intel/iwlegacy/commands.h:2667:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
>> 4 drivers/net/wireless/intel/iwlegacy/3945.h:131:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
>
> Yay for getting these gone! :)
>
We're getting there! \o/
Thanks
-Gustavo
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Bitterblue Smith @ 2026-02-09 20:53 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <04799d469547468abe15eadb2ec74255@realtek.com>
On 09/02/2026 10:19, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
>> NetworkManager?) triggers a scan every five minutes. During these scans
>> mac80211 transmits many QoS Null frames in quick succession. Because
>> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
>> asks the firmware to report the TX ACK status for each of these frames.
>> Sometimes the firmware can't process the TX status requests quickly
>> enough, they add up, it only processes some of them, and then marks
>> every subsequent TX status report with the wrong number.
>
> Does it mean number of reports is correct? But with incorrect sequence number?
> Then, you just ignore checking 'sn' but assume 'st' is correct.
>
The number of reports is correct most of the time. Only when the firmware
is overwhelmed (?) it doesn't provide every report, but later it recovers.
I added some debugging messages:
[...]
[ 1360.012011] queueing tx report request with sn 144
[ 1360.032820] received tx report with sn 144
[ 1360.157378] queueing tx report request with sn 148
[ 1360.158402] received tx report with sn 148
[ 1360.360006] queueing tx report request with sn 152
[ 1360.380687] received tx report with sn 152
[ 1360.505498] queueing tx report request with sn 156
[ 1360.507455] received tx report with sn 156
[ 1360.708000] queueing tx report request with sn 160
[ 1360.728808] received tx report with sn 160
[ 1360.853490] queueing tx report request with sn 164
[ 1360.857279] received tx report with sn 164
[ 1361.055993] queueing tx report request with sn 168
[ 1361.076800] received tx report with sn 168
[ 1361.201610] queueing tx report request with sn 172
[ 1361.203468] received tx report with sn 172
[ 1361.403988] queueing tx report request with sn 176
[ 1361.445670] received tx report with sn 176
[ 1361.601977] queueing tx report request with sn 180
[ 1361.605731] queueing tx report request with sn 184
[ 1361.611737] queueing tx report request with sn 188
[ 1361.612000] received tx report with sn 180
[ 1361.612090] received tx report with sn 184
[ 1361.615321] received tx report with sn 188
(5 minutes later, another scan:)
[ 1658.918266] queueing tx report request with sn 192
[ 1658.924667] received tx report with sn 192
[ 1659.069240] queueing tx report request with sn 196
[ 1659.075545] received tx report with sn 196
[ 1659.271741] queueing tx report request with sn 200
[ 1659.291789] received tx report with sn 200
[ 1659.417107] queueing tx report request with sn 204
[ 1659.421960] received tx report with sn 204
[ 1659.619861] queueing tx report request with sn 208
[ 1659.639910] received tx report with sn 208
[ 1659.765229] queueing tx report request with sn 212
[ 1659.770078] received tx report with sn 212
[ 1659.967855] queueing tx report request with sn 216
[ 1659.987905] received tx report with sn 216
[ 1660.113223] queueing tx report request with sn 220
[ 1660.118074] received tx report with sn 220
[ 1660.315852] queueing tx report request with sn 224
[ 1660.335900] received tx report with sn 224
[ 1660.461215] queueing tx report request with sn 228
[ 1660.466067] received tx report with sn 228
[ 1660.663845] queueing tx report request with sn 232
[ 1660.683895] received tx report with sn 232
[ 1660.809208] queueing tx report request with sn 236
[ 1660.814056] received tx report with sn 236
[ 1661.011840] queueing tx report request with sn 240
[ 1661.031886] received tx report with sn 240
[ 1661.157204] queueing tx report request with sn 244
[ 1661.158197] received tx report with sn 244
[ 1661.359836] queueing tx report request with sn 248
[ 1661.379878] received tx report with sn 248
[ 1661.528327] queueing tx report request with sn 252
[ 1661.528360] queueing tx report request with sn 0
[ 1661.528573] queueing tx report request with sn 4
[ 1661.530424] received tx report with sn 4
[ 1661.535689] received tx report with sn 252
[ 1662.058688] rtw_8723du 1-1:1.2: still have 1 unprocessed tx report requests
(5 minutes later, another scan:)
[ 1958.926214] queueing tx report request with sn 8
[ 1958.931871] received tx report with sn 0
[ 1959.077185] queueing tx report request with sn 12
[ 1959.081971] received tx report with sn 8
[ 1959.279810] queueing tx report request with sn 16
[ 1959.299858] received tx report with sn 12
[ 1959.425182] queueing tx report request with sn 20
[ 1959.429951] received tx report with sn 16
[ 1959.627801] queueing tx report request with sn 24
[ 1959.647852] received tx report with sn 20
[ 1959.773173] queueing tx report request with sn 28
[ 1959.777942] received tx report with sn 24
[ 1959.975800] queueing tx report request with sn 32
[ 1959.995844] received tx report with sn 216
[ 1960.121163] queueing tx report request with sn 36
[ 1960.125935] received tx report with sn 32
[ 1960.323788] queueing tx report request with sn 40
[ 1960.343840] received tx report with sn 36
[ 1960.469162] queueing tx report request with sn 44
[ 1960.473955] received tx report with sn 40
[ 1960.671784] queueing tx report request with sn 48
[ 1960.691711] received tx report with sn 44
[ 1960.817278] queueing tx report request with sn 52
[ 1960.822047] received tx report with sn 48
[ 1961.019780] queueing tx report request with sn 56
[ 1961.039704] received tx report with sn 52
[ 1961.165150] queueing tx report request with sn 60
[ 1961.169920] received tx report with sn 56
[ 1961.367772] queueing tx report request with sn 64
[ 1961.387701] received tx report with sn 60
[ 1961.535771] queueing tx report request with sn 68
[ 1961.535805] queueing tx report request with sn 72
[ 1961.536015] queueing tx report request with sn 76
[ 1961.537739] received tx report with sn 64
[ 1961.543622] received tx report with sn 76
[ 1961.543655] received tx report with sn 68
[ 1962.058691] rtw_8723du 1-1:1.2: still have 2 unprocessed tx report requests
Here the number of reports matches the number of requests.
I assume st is correct, but I'm not sure how to test that.
(5 minutes later, another scan:)
[ 2258.930888] queueing tx report request with sn 80
[ 2258.931968] received tx report with sn 72
[ 2259.074009] queueing tx report request with sn 84
[ 2259.075296] received tx report with sn 80
[ 2259.276268] queueing tx report request with sn 88
[ 2259.292578] received tx report with sn 84
[ 2259.417771] queueing tx report request with sn 92
[ 2259.421069] received tx report with sn 88
[ 2259.620249] queueing tx report request with sn 96
[ 2259.636439] received tx report with sn 0
[ 2259.761876] queueing tx report request with sn 100
[ 2259.763314] received tx report with sn 96
[ 2259.964239] queueing tx report request with sn 104
[ 2260.006304] received tx report with sn 100
[ 2260.129871] queueing tx report request with sn 108
[ 2260.131799] received tx report with sn 104
[ 2260.332240] queueing tx report request with sn 112
[ 2260.348426] received tx report with sn 108
[ 2260.473732] queueing tx report request with sn 116
[ 2260.475262] received tx report with sn 112
[ 2260.680223] queueing tx report request with sn 120
[ 2260.737903] received tx report with sn 116
[ 2260.870463] queueing tx report request with sn 124
[ 2260.885589] received tx report with sn 120
[ 2261.071970] queueing tx report request with sn 128
[ 2261.213583] queueing tx report request with sn 132
[ 2261.416138] queueing tx report request with sn 136
[ 2261.576217] queueing tx report request with sn 140
[ 2261.576323] queueing tx report request with sn 144
[ 2261.828937] received tx report with sn 124
[ 2262.090722] rtw_8723du 1-1:1.2: still have 6 unprocessed tx report requests
[ 2262.470953] queueing tx report request with sn 148
[ 2262.472454] received tx report with sn 144
[ 2262.986738] rtw_8723du 1-1:1.2: still have 1 unprocessed tx report requests
>>
>> The symptom is that after a while the warning "failed to get tx report
>> from firmware" appears every five minutes.
>>
>> This problem apparently happens only with the older RTL8723D, RTL8821A,
>> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
>> number reported by these chips and match the reports with the requests
>> in the order they come in.
>>
>> Tested with RTL8821AU and RTL8723DU.
>>
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>> ---
>> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
>> index c04ff31d0f1e..98215ecc884a 100644
>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
>> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
>> spin_lock_irqsave(&tx_report->q_lock, flags);
>> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
>> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
>> - if (*n == sn) {
>> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
>
> Can we only limit to USB devices (or non-PCI devices)?
>
I don't think so. RTL8821AE also has this problem. I didn't mention it
in the commit message because support for RTL8821AE in rtw88 is
unofficial. (I modified rtw88_pci to handle the older generation, see
the use_new_trx_flow=false code path in rtlwifi.)
>> __skb_unlink(cur, &tx_report->queue);
>> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
>> break;
>> --
>> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v2][next] iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warnings
From: Kees Cook @ 2026-02-09 20:46 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Stanislaw Gruszka, Johannes Berg, linux-wireless, linux-kernel,
linux-hardening
In-Reply-To: <aYlkt2WP2oQ1TgeH@kspp>
On Mon, Feb 09, 2026 at 01:38:15PM +0900, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Move the conflicting declarations (which in a couple of cases happen
> to be in a union, so the entire unions are moved) to the end of the
> corresponding structures. Notice that `struct il_tx_beacon_cmd`,
> `struct il4965_tx_resp`, and `struct il3945_tx_beacon_cmd` are flexible
> structures, this is structures that contain a flexible-array member.
I think explicit mention of il3945_frame and il_frame should be included
in the commit log (probably after the above), as they are the ones that
contain the mentioned il*_tx_beacon_cmd structs that have a trailing
flex array.
> The case for struct il4965_beacon_notif is different. Since this
> structure is defined by hardware, we use the struct_group() helper
> to create the new `struct il4965_tx_resp_hdr` type. We then use this newly
> created type to replace the obhect type of causing trouble in
> struct il4965_beacon_notif, namely `stryct il4965_tx_resp`.
Above two lines have typos and maybe a missing name (between "of" and
"causing")?
> In order to preserve the memory layout in struct il4965_beacon_notif,
> add member `__le32 beacon_tx_status`, which was previously included
> by `struct il4965_tx_resp` (as `__le32 status`), but it's not present
> in the newly created type `struct il4965_tx_resp_hdr`.
It may help to explicitly mention how the union exists to provide the
"status" member to anything using struct il4965_tx_resp, but there's no
sane way to do the overlap across structs, so anything using
il4965_beacon_notif needs have its own view of "status".
It does feel like accessing il4965_tx_resp's agg_status should be using
a different struct (like happens for other things that want bytes beyond
"status"), but okay.
Anyway, it's another situation of a header with a trailing flex array
that needs to overlap with differing deserializations of the trailing
bytes. The complication here is the kind of "layering violation" of
agg_status and status.
> Notice that after this changes, the size of struct il4965_beacon_notif
> along with its member's offsets remain the same, hence the memory
> layout doesn't change:
>
> Before changes:
> struct il4965_beacon_notif {
> struct il4965_tx_resp beacon_notify_hdr; /* 0 24 */
> __le32 low_tsf; /* 24 4 */
> __le32 high_tsf; /* 28 4 */
> __le32 ibss_mgr_status; /* 32 4 */
>
> /* size: 36, cachelines: 1, members: 4 */
> /* last cacheline: 36 bytes */
> };
>
> After changes:
> struct il4965_beacon_notif {
> struct il4965_tx_resp_hdr beacon_notify_hdr; /* 0 20 */
> __le32 beacon_tx_status; /* 20 4 */
> __le32 low_tsf; /* 24 4 */
> __le32 high_tsf; /* 28 4 */
> __le32 ibss_mgr_status; /* 32 4 */
>
> /* size: 36, cachelines: 1, members: 5 */
> /* last cacheline: 36 bytes */
> };
>
> We also want to ensure that when new members are added to the flexible
> structure `struct il4965_tx_resp` (if any), they are always included
> within the newly created struct type. To enforce this, we use
> `static_assert()` (which is intentionally placed right after the struct,
> this is, no blank line in between). This ensures that the memory layout
> of both the flexible structure and the new `struct il4965_tx_resp_hdr`
> type remains consistent after any changes.
>
> Lastly, refactor the rest of the code, accordingly.
I think the changes look consistent with other similar logical changes
that have been made for -Wfamnae.
Since enabling -fms-extensions I'm on the look-out for cases where
we can use transparent struct members (i.e. define the header struct
separately and then use it transparently) instead of using the struct
group when we don't need to make the interior explicitly addressable
(as we have in this case), as it makes the diff way smaller:
diff --git a/drivers/net/wireless/intel/iwlegacy/commands.h b/drivers/net/wireless/intel/iwlegacy/commands.h
index b61b8f377702..440dff2a4ad9 100644
--- a/drivers/net/wireless/intel/iwlegacy/commands.h
+++ b/drivers/net/wireless/intel/iwlegacy/commands.h
@@ -1690,7 +1690,7 @@ struct agg_tx_status {
__le16 sequence;
} __packed;
-struct il4965_tx_resp {
+struct il4965_tx_resp_hdr {
u8 frame_count; /* 1 no aggregation, >1 aggregation */
u8 bt_kill_count; /* # blocked by bluetooth (unused for agg) */
u8 failure_rts; /* # failures due to unsuccessful RTS */
@@ -1707,6 +1707,10 @@ struct il4965_tx_resp {
__le16 reserved;
__le32 pa_power1; /* RF power amplifier measurement (not used) */
__le32 pa_power2;
+} __packed;
+
+struct il4965_tx_resp {
+ struct il4965_tx_resp_hdr;
/*
* For non-agg: frame status TX_STATUS_*
@@ -2664,7 +2668,8 @@ struct il3945_beacon_notif {
} __packed;
struct il4965_beacon_notif {
- struct il4965_tx_resp beacon_notify_hdr;
+ struct il4965_tx_resp_hdr beacon_notify_hdr;
+ __le32 status;
__le32 low_tsf;
__le32 high_tsf;
__le32 ibss_mgr_status;
What do folks think?
> With these changes fix the following warnings:
>
> 11 drivers/net/wireless/intel/iwlegacy/common.h:526:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> 11 drivers/net/wireless/intel/iwlegacy/commands.h:2667:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> 4 drivers/net/wireless/intel/iwlegacy/3945.h:131:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Yay for getting these gone! :)
--
Kees Cook
^ permalink raw reply related
* [PATCH v2][next] iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warnings
From: Gustavo A. R. Silva @ 2026-02-09 4:38 UTC (permalink / raw)
To: Stanislaw Gruszka, Johannes Berg
Cc: linux-wireless, linux-kernel, Gustavo A. R. Silva,
linux-hardening, Kees Cook
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Move the conflicting declarations (which in a couple of cases happen
to be in a union, so the entire unions are moved) to the end of the
corresponding structures. Notice that `struct il_tx_beacon_cmd`,
`struct il4965_tx_resp`, and `struct il3945_tx_beacon_cmd` are flexible
structures, this is structures that contain a flexible-array member.
The case for struct il4965_beacon_notif is different. Since this
structure is defined by hardware, we use the struct_group() helper
to create the new `struct il4965_tx_resp_hdr` type. We then use this newly
created type to replace the obhect type of causing trouble in
struct il4965_beacon_notif, namely `stryct il4965_tx_resp`.
In order to preserve the memory layout in struct il4965_beacon_notif,
add member `__le32 beacon_tx_status`, which was previously included
by `struct il4965_tx_resp` (as `__le32 status`), but it's not present
in the newly created type `struct il4965_tx_resp_hdr`.
Notice that after this changes, the size of struct il4965_beacon_notif
along with its member's offsets remain the same, hence the memory
layout doesn't change:
Before changes:
struct il4965_beacon_notif {
struct il4965_tx_resp beacon_notify_hdr; /* 0 24 */
__le32 low_tsf; /* 24 4 */
__le32 high_tsf; /* 28 4 */
__le32 ibss_mgr_status; /* 32 4 */
/* size: 36, cachelines: 1, members: 4 */
/* last cacheline: 36 bytes */
};
After changes:
struct il4965_beacon_notif {
struct il4965_tx_resp_hdr beacon_notify_hdr; /* 0 20 */
__le32 beacon_tx_status; /* 20 4 */
__le32 low_tsf; /* 24 4 */
__le32 high_tsf; /* 28 4 */
__le32 ibss_mgr_status; /* 32 4 */
/* size: 36, cachelines: 1, members: 5 */
/* last cacheline: 36 bytes */
};
We also want to ensure that when new members are added to the flexible
structure `struct il4965_tx_resp` (if any), they are always included
within the newly created struct type. To enforce this, we use
`static_assert()` (which is intentionally placed right after the struct,
this is, no blank line in between). This ensures that the memory layout
of both the flexible structure and the new `struct il4965_tx_resp_hdr`
type remains consistent after any changes.
Lastly, refactor the rest of the code, accordingly.
With these changes fix the following warnings:
11 drivers/net/wireless/intel/iwlegacy/common.h:526:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
11 drivers/net/wireless/intel/iwlegacy/commands.h:2667:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
4 drivers/net/wireless/intel/iwlegacy/3945.h:131:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
Changes in v2:
- Use the struct_group() helper, and update the conflicting type
(struct il4965_tx_resp -> struct il4965_tx_resp_hdr) in
struct il4965_beacon_notif.
v1:
- Link: https://lore.kernel.org/linux-hardening/aR2CtqZI3atH0HmE@kspp/
drivers/net/wireless/intel/iwlegacy/3945.h | 4 +-
.../net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
.../net/wireless/intel/iwlegacy/commands.h | 41 +++++++++++--------
drivers/net/wireless/intel/iwlegacy/common.h | 4 +-
4 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/3945.h b/drivers/net/wireless/intel/iwlegacy/3945.h
index fb1e33c89d0e..ed63b31fee9a 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945.h
+++ b/drivers/net/wireless/intel/iwlegacy/3945.h
@@ -123,13 +123,15 @@ enum il3945_antenna {
#define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN)
struct il3945_frame {
+ struct list_head list;
+
+ /* Must be last as it ends in a flexible-array member. */
union {
struct ieee80211_hdr frame;
struct il3945_tx_beacon_cmd beacon;
u8 raw[IEEE80211_FRAME_LEN];
u8 cmd[360];
} u;
- struct list_head list;
};
#define SUP_RATE_11A_MAX_NUM_CHANNELS 8
diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
index 57fa866efd9f..f5a99a2ee95a 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
@@ -4076,7 +4076,7 @@ il4965_hdl_beacon(struct il_priv *il, struct il_rx_buf *rxb)
u8 rate = il4965_hw_get_rate(beacon->beacon_notify_hdr.rate_n_flags);
D_RX("beacon status %x retries %d iss %d tsf:0x%.8x%.8x rate %d\n",
- le32_to_cpu(beacon->beacon_notify_hdr.u.status) & TX_STATUS_MSK,
+ le32_to_cpu(beacon->beacon_tx_status) & TX_STATUS_MSK,
beacon->beacon_notify_hdr.failure_frame,
le32_to_cpu(beacon->ibss_mgr_status),
le32_to_cpu(beacon->high_tsf), le32_to_cpu(beacon->low_tsf), rate);
diff --git a/drivers/net/wireless/intel/iwlegacy/commands.h b/drivers/net/wireless/intel/iwlegacy/commands.h
index b61b8f377702..630bc12cd0d5 100644
--- a/drivers/net/wireless/intel/iwlegacy/commands.h
+++ b/drivers/net/wireless/intel/iwlegacy/commands.h
@@ -1691,22 +1691,25 @@ struct agg_tx_status {
} __packed;
struct il4965_tx_resp {
- u8 frame_count; /* 1 no aggregation, >1 aggregation */
- u8 bt_kill_count; /* # blocked by bluetooth (unused for agg) */
- u8 failure_rts; /* # failures due to unsuccessful RTS */
- u8 failure_frame; /* # failures due to no ACK (unused for agg) */
-
- /* For non-agg: Rate at which frame was successful.
- * For agg: Rate at which all frames were transmitted. */
- __le32 rate_n_flags; /* RATE_MCS_* */
-
- /* For non-agg: RTS + CTS + frame tx attempts time + ACK.
- * For agg: RTS + CTS + aggregation tx time + block-ack time. */
- __le16 wireless_media_time; /* uSecs */
-
- __le16 reserved;
- __le32 pa_power1; /* RF power amplifier measurement (not used) */
- __le32 pa_power2;
+ /* New members MUST be added within the __struct_group() macro below. */
+ __struct_group(il4965_tx_resp_hdr, __hdr, __packed,
+ u8 frame_count; /* 1 no aggregation, >1 aggregation */
+ u8 bt_kill_count; /* # blocked by bluetooth (unused for agg) */
+ u8 failure_rts; /* # failures due to unsuccessful RTS */
+ u8 failure_frame; /* # failures due to no ACK (unused for agg) */
+
+ /* For non-agg: Rate at which frame was successful.
+ * For agg: Rate at which all frames were transmitted. */
+ __le32 rate_n_flags; /* RATE_MCS_* */
+
+ /* For non-agg: RTS + CTS + frame tx attempts time + ACK.
+ * For agg: RTS + CTS + aggregation tx time + block-ack time. */
+ __le16 wireless_media_time; /* uSecs */
+
+ __le16 reserved;
+ __le32 pa_power1; /* RF power amplifier measurement (not used) */
+ __le32 pa_power2;
+ );
/*
* For non-agg: frame status TX_STATUS_*
@@ -1726,6 +1729,9 @@ struct il4965_tx_resp {
DECLARE_FLEX_ARRAY(struct agg_tx_status, agg_status); /* for each agg frame */
} u;
} __packed;
+static_assert(offsetof(struct il4965_tx_resp, u.agg_status) ==
+ sizeof(struct il4965_tx_resp_hdr),
+ "struct member likely outside of __struct_group()");
/*
* N_COMPRESSED_BA = 0xc5 (response only, not a command)
@@ -2664,7 +2670,8 @@ struct il3945_beacon_notif {
} __packed;
struct il4965_beacon_notif {
- struct il4965_tx_resp beacon_notify_hdr;
+ struct il4965_tx_resp_hdr beacon_notify_hdr;
+ __le32 beacon_tx_status;
__le32 low_tsf;
__le32 high_tsf;
__le32 ibss_mgr_status;
diff --git a/drivers/net/wireless/intel/iwlegacy/common.h b/drivers/net/wireless/intel/iwlegacy/common.h
index 4c9836ab11dd..21f1c7702add 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.h
+++ b/drivers/net/wireless/intel/iwlegacy/common.h
@@ -518,13 +518,15 @@ struct il_channel_info {
#define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN)
struct il_frame {
+ struct list_head list;
+
+ /* Must be last as it ends in a flexible-array member. */
union {
struct ieee80211_hdr frame;
struct il_tx_beacon_cmd beacon;
u8 raw[IEEE80211_FRAME_LEN];
u8 cmd[360];
} u;
- struct list_head list;
};
enum {
--
2.43.0
^ permalink raw reply related
* [PATCH wireless v2] wifi: cfg80211: wext: fix IGTK key ID off-by-one
From: Johannes Berg @ 2026-02-09 18:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Jouni Malinen
From: Johannes Berg <johannes.berg@intel.com>
The IGTK key ID must be 4 or 5, but the code checks against
key ID + 1, so must check against 5/6 rather than 4/5. Fix
that.
Reported-by: Jouni Malinen <j@w1.fi>
Fixes: 08645126dd24 ("cfg80211: implement wext key handling")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 1241fda78a68..680500fa57cf 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -684,7 +684,7 @@ static int cfg80211_wext_siwencodeext(struct net_device *dev,
idx = erq->flags & IW_ENCODE_INDEX;
if (cipher == WLAN_CIPHER_SUITE_AES_CMAC) {
- if (idx < 4 || idx > 5) {
+ if (idx < 5 || idx > 6) {
idx = wdev->wext.default_mgmt_key;
if (idx < 0)
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* [PATCH wireless] wifi: cfg80211: wext: fix IGTK key ID off-by-one
From: Johannes Berg @ 2026-02-09 17:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Jouni Malinen
From: Johannes Berg <johannes.berg@intel.com>
The IGTK key ID must be 4 or 5, but the code checks against
key ID + 1, so must check against 5/6 rather than 4/5. Fix
that.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 1241fda78a68..680500fa57cf 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -684,7 +684,7 @@ static int cfg80211_wext_siwencodeext(struct net_device *dev,
idx = erq->flags & IW_ENCODE_INDEX;
if (cipher == WLAN_CIPHER_SUITE_AES_CMAC) {
- if (idx < 4 || idx > 5) {
+ if (idx < 5 || idx > 6) {
idx = wdev->wext.default_mgmt_key;
if (idx < 0)
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] AP: Always re-add stations that use MLO
From: Ramasamy Kaliappan @ 2026-02-09 14:56 UTC (permalink / raw)
To: Benjamin Berg, Rameshkumar Sundaram, hostap, jouni.malinen
Cc: linux-wireless, Andrei Otcheretianski
In-Reply-To: <3643c9d1111a0076c7d420a16d0f97c29ac6575d.camel@sipsolutions.net>
On 2/6/2026 2:35 PM, Benjamin Berg wrote:
> On Thu, 2026-02-05 at 22:34 +0530, Ramasamy Kaliappan wrote:
>> Hi,
>>
>> On 1/30/2026 5:32 PM, Benjamin Berg wrote:
>>> Hi,
>>>
>>> On Thu, 2026-01-29 at 22:56 +0530, Rameshkumar Sundaram wrote:
>>>> On 1/29/2026 3:38 PM, Benjamin Berg wrote:
>>>>> [SNIP]
>>>>> That said, to properly fix this we need an nl80211/mac80211 API that
>>>>> permits us to disable address translation for the frame. Otherwise we
>>>>> would still get the address translated to the old link address should
>>>>> the new link address match the MLD address.
>>>>>
>>>>
>>>> That's true—even probe responses get translated when the old link
>>>> address matches the new link MLD address.
>>>>
>>>> Few other cases I encountered:
>>>> Consider an ML STA with ML address M associated with link A and link B,
>>>> using link addresses X and Y respectively. If the STA sends an
>>>> authentication frame with address Y on link A, it gets translated to M
>>>> (even though link A has no STA with address Y) and forwarded to link B.
>>>> As a result, hostapd is unaware of the actual TA and queues the
>>>> authentication reply to the MLD address on link B. This frame will
>>>> eventually be transmitted over the air on link B with address Y.
>>>
>>> Honestly, that type of link confusion seems like a bug. We should be
>>> able to avoid that as we hopefully know on which link the frame was
>>> received.
>>>
>>>> This will be true even if STA associated in one link and tries to roam
>>>> to other link of MLD using same link and ML addresses.
>>>>
>>>> There also cases where an ML STA roams/re-associates as legacy (non-ML)
>>>> STA with ML address as link address. The reply would go out with old
>>>> link address.
>>>
>>> Yes, I think that case is similar a station using its MLD Address on
>>> the association link and returning on another link.
>>>
>>>> It seems that address translation at the driver/mac80211 level for
>>>> management frames could be avoided for both TX and RX, allowing hostapd
>>>> to handle these frames and their replies more efficiently in cases of
>>>> roaming and address reuse.
>>>
>>> Doing address translation in the TX path is required if the
>>> hardware/driver should decide on which link to TX the frame. For RX, it
>>> seems sensible to me to do the translation when it is possible.
>>>
>>> I talked a bit to Johannes about this today, and my current proposal
>>> would be add a new flag that is set when mac80211 did not find (RX) or
>>> should not use (TX) a STA for the frame.
>>>
>>> More specifically I think that we could:
>>> * Fix the link address based STA lookup to only work when the frame
>>> was received on the correct link (the bug from above).
>>> * Make sure we drop robust management frames without a STA as we do
>>> not want to get into trouble with the next change.
>>> * Change ieee80211_rx_for_interface so that it uses only
>>> link_sta_info_get_bss if we are an MLD and sta_info_get_bss
>>> otherwise.
>>> Right now, we will find the station if we see the MLD Address in the
>>> frame even when it is not a valid link address.
>>> * Add a new nl80211 attribute NL80211_ATTR_FRAME_NO_STA to be used
>>> together with NL80211_CMD_FRAME for both TX and RX.
>>> - In the RX case, add the attribute if we have no station. If the
>>> attribute does not exist, then hostapd should assume the address was
>>> translated.
>>> - In the TX case, plumb the information through to mac80211 and avoid
>>> doing a station lookup based on the address.
>>>
>>> I think this would be enough to then solve the problem in hostapd.
>>>
>>
>> I feel this approach should work. I'm trying to understand how it
>> behaves in the following scenario where the STA reconnects with the same
>> link address but a new(different) MLD address.
>>
>> Consider a situation where an already associated STA sends a reconnect
>> request using the same link addresses but a different MLD address.
>>
>> For example, assume the station was originally connected using M as the
>> MLD address, with L1 and L2 as its link addresses. When the STA
>> reconnects (or roam back), it may use a new MLD address B while still
>> using the same link addresses L1 and L2.
>>
>> In such a case, mac80211 will still find the existing STA entry based on
>> the link address, and address translation would map the link address to
>> the old mld address. Since the STA lookup succeeds,
>> NL80211_ATTR_FRAME_NO_STA would be set to 0.
>>
>> How is this expected to be handled in hostapd? I believe hostapd will
>> also need additional logic to correctly handle this case, since the
>> link address maps to an already‑known STA, but the MLD address has changed.
>> Otherwise, hostapd may end up replying to the old MLD address or
>> associating the frame with the wrong MLD context.
>
> I am not sure we really need to care about this case, but, I think we
> can handle it just fine if we want to.
>
> In this case is mac80211 would translate the address to the MLD Address
> and would not include the NO_STA flag. hostapd can look up the MLD
> Address in its database and translate the address back to the link
> address for its internal use. It can also explicitly TX the response to
> the link address by setting the NO_STA flag.
>
> So, I think it is an interesting corner case and we need to make sure
> to not get confused by it. But, hostapd should be able to handle it.
> Either by simply rejecting the AUTH or by making sure the MLD addresses
> are all correct if the association succeeds.
>
> Btw. I did start looking into doing the mac80211/cfg80211 changes. How
> should we do it with hostapd? Is someone on your side maybe able to
> work on the hostapd part?
>
Sure, we will work on the hostapd side once you post the
mac80211/cfg80211 changes.
The below few test scenarios we have observed with various IoT client
behaviors. These are cases hostapd/mac80211 must correctly interpret the
frame origin and address mappings.
These scenarios involve address reuse, link address swapping, and mixed
MLD/legacy reconnection patterns seen during roaming or second
connection request:
1. AP MLD with 3 links (wlan0): a legacy (non‑MLD) station initially
connects on 5 GHz and later roams back legacy station to the 6 GHz link
of the same AP MLD.
2. AP MLD with 3 links: a SLO station initially connects to 5 GHz using
link address L1 and MLD address M1, then attempts to reconnect on the
same 5 GHz link using only the MLD address M1.
Incoming probe/auth/assoc frames use the MLD address → link/MLD address
swapping occurs.
3. MLD AP with 3 links: SLO STA is initially connected on 5 GHz (L1,
M1). Second connection same station attempts to connect on 6 GHz using
L1 address(5GHz link address). it sends probe/auth/assoc frames on
6 GHz using the 5 GHz link address L1 with the same MLD address M1.
4. MLD AP with 3 links: Initial SLO station connected (L1, M1 on 5 GHz).
Second connection same station attempts to connect on 6 GHz using the
MLD address M1.
5. MLD AP with 3 links: an MLD STA is connected on 5 GHz + 6 GHz. A
legacy STA later attempts to reconnect using the same MLD address on
5 /6 GHz.
6. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
another 2‑link MLD STA using (L1, L2, M1).
7. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
another STA using (L2, L1, M) (links swapped).
8. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
STA uses (L1, M, L2).
9. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
STA uses (M, L2, L1).
10.Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
STA uses (L1, M, M1).
11.Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
STA uses (M, L2, M1).
12.Initial connection: 2‑link MLD STA (L1, L2, M). Second connection:
STA uses (M, A, M1) (A = a new link address).
We need to clarify how NL80211_ATTR_FRAME_NO_STA will be handled in each
of these cases.
@Jouni- These corner‑case behaviors were observed with some of IOT
clients. Handling this attribute within hostapd introduces some
additional logic to find appropriate sta, source address for received
frames and destination address to response.
Please share your thoughts on this approach?
> Benjamin
^ permalink raw reply
* Re: [PATCH] mesh: don't incorrectly use const
From: Johannes Berg @ 2026-02-09 12:39 UTC (permalink / raw)
To: Rudi Heitbaum; +Cc: linux-wireless
In-Reply-To: <aYh28AFauAnhkzee@c1ec8b16bbaa>
On Sun, 2026-02-08 at 11:45 +0000, Rudi Heitbaum wrote:
>
> --- a/mesh.c
> +++ b/mesh.c
What's this for? Maybe 'iw'? Please use (also) that for subject prefix
if so.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
From: Johannes Berg @ 2026-02-09 11:50 UTC (permalink / raw)
To: Sai Pratyusha Magam; +Cc: linux-wireless, quic_drohan
In-Reply-To: <ff9330f7e17da9c7c1ba87b9400051a9bec29aa4.camel@sipsolutions.net>
On Mon, 2026-02-09 at 12:27 +0100, Johannes Berg wrote:
>
> If I restrict hwsim [1] to only pairwise and CCMP/GCMP (clearly it
> doesn't handle TKIP due to Michael MIC, WEP is irrelevant, BIGTK isn't
> handled in hwsim), then it mostly works without all of that extra logic
> for me for the tests. Maybe need to think about IGTK here though, some
> tests are still failing.
>
> [1] https://p.sipsolutions.net/d101bc31582cadcf.txt
Oh I guess that should be 'return 1' and hwsim would have to call the
encrypt for data frames before address translation ... But the more we
can push into hwsim, the better IMHO.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
From: Johannes Berg @ 2026-02-09 11:27 UTC (permalink / raw)
To: Sai Pratyusha Magam; +Cc: linux-wireless, quic_drohan
In-Reply-To: <20260208081854.1080048-1-sai.magam@oss.qualcomm.com>
Hi,
So that looks like a huge improvement to me, nice! :-)
On Sun, 2026-02-08 at 13:48 +0530, Sai Pratyusha Magam wrote:
> The hybrid way of having both HW/driver based crypto for certain frames
> and SW crypto for others require that the fast-xmit path be skipped
> when the above mentioned key flag is set, since data frames still rely
> on software based crypto
I can understand this sentence in the sense of "A => B", and it
describes why B follows from A, but ... why do you even need A? I.e. why
do you want to do this for management frames only, it seems the encrypt
function and having hwsim worry about it should work just as well for
data frames?
If I restrict hwsim [1] to only pairwise and CCMP/GCMP (clearly it
doesn't handle TKIP due to Michael MIC, WEP is irrelevant, BIGTK isn't
handled in hwsim), then it mostly works without all of that extra logic
for me for the tests. Maybe need to think about IGTK here though, some
tests are still failing.
[1] https://p.sipsolutions.net/d101bc31582cadcf.txt
But if we do that (even if I don't like it, I'd rather fix the remaining
issues), then you need to document reason for it.
johannes
^ permalink raw reply
* [bug report] wifi: mwifiex: Allocate dev name earlier for interface workqueue name
From: Dan Carpenter @ 2026-02-09 9:43 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Francesco Dolcini, linux-wireless, linux-kernel
In-Reply-To: <caa37f28-a2e8-4e0a-a9ce-a365ce805e4b@stanley.mountain>
[ Smatch checking is paused while we raise funding. #SadFace
https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]
Hello Chen-Yu Tsai,
Commit 7bab5bdb81e3 ("wifi: mwifiex: Allocate dev name earlier for
interface workqueue name") from Jan 7, 2026 (linux-next), leads to
the following Smatch static checker warning:
drivers/net/wireless/marvell/mwifiex/cfg80211.c:3214 mwifiex_add_virtual_intf()
warn: passing positive error code '(-23)-(-22),(-12),1-64' to 'ERR_PTR'
drivers/net/wireless/marvell/mwifiex/cfg80211.c
3147
3148 SET_NETDEV_DEV(dev, adapter->dev);
3149
3150 ret = dev_alloc_name(dev, name);
3151 if (ret)
3152 goto err_alloc_name;
The dev_alloc_name() function can return 1-64 if the name has a "%d" in
it. None of the other nine callers use the positive returns. The only
thing it does is cause a crash here. We should probably fix
dev_alloc_name() as well as changing this to if (ret < 0) {.
3153
3154 priv->dfs_cac_workqueue = alloc_workqueue("MWIFIEX_DFS_CAC-%s",
3155 WQ_HIGHPRI |
3156 WQ_MEM_RECLAIM |
3157 WQ_UNBOUND, 0, dev->name);
3158 if (!priv->dfs_cac_workqueue) {
3159 mwifiex_dbg(adapter, ERROR, "cannot alloc DFS CAC queue\n");
3160 ret = -ENOMEM;
3161 goto err_alloc_cac;
3162 }
3163
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: fix backoff fields and max_power calculation
From: Sven Eckelmann @ 2026-02-09 9:17 UTC (permalink / raw)
To: robh@kernel.org, Ryder Lee
Cc: linux-wireless@vger.kernel.org, nbd@nbd.name,
linux-mediatek@lists.infradead.org,
Allen Ye (葉芷勳), saravanak@kernel.org
In-Reply-To: <278546e3f3e526288d245111d8e022b2d68d012e.camel@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]
On Monday, 9 February 2026 08:48:50 CET Ryder Lee wrote:
> - In connac2, beamforming entries for BW20~BW160 and OFDM do not
> include 1T1ss.
> - In connac3, beamforming entries for BW20~BW160 and RU include 1T1ss,
> but OFDM beamforming does not include 1T1ss.
This doesn't seem to match the documentation [1]:
paths-ofdm-bf:
$ref: /schemas/types.yaml#/definitions/uint8-array
minItems: 4
maxItems: 4
description:
4 half-dBm backoff values for beamforming
(1 - 4 antennas, single spacial stream)
...
paths-ru-bf:
$ref: /schemas/types.yaml#/definitions/uint8-matrix
description:
Sets of half-dBm backoff (beamforming) values for 802.11ax
rates for 1T1ss (aka 1 transmitting antenna with 1 spacial
stream), 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss,
4T3ss and 4T4ss.
Each set starts with the number of channel bandwidth or
resource unit settings for which the rate set applies,
followed by 10 power limit values. The order of the
channel resource unit settings is RU26, RU52, RU106,
RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
minItems: 1
maxItems: 7
items:
minItems: 11
maxItems: 11
Regards,
Sven
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/net/wireless/mediatek%2Cmt76.yaml
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* RE: [PATCH] wifi: iwlwifi: ptp: Fix potential race condition in PTP removal
From: Korenblit, Miriam Rachel @ 2026-02-09 8:32 UTC (permalink / raw)
To: Cao, Junjie, Berg, Johannes, linux-wireless@vger.kernel.org,
Richard Cochran
Cc: Simon Horman, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Ben Shimol, Yedidya, Stern, Avraham,
Gabay, Daniel, Prabhu, Krishnanand, Coelho, Luciano,
Gregory Greenman, stable@vger.kernel.org
In-Reply-To: <20260115161529.85720-1-junjie.cao@intel.com>
> -----Original Message-----
> From: Cao, Junjie <junjie.cao@intel.com>
> Sent: Thursday, January 15, 2026 6:15 PM
> To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>; Berg,
> Johannes <johannes.berg@intel.com>; linux-wireless@vger.kernel.org; Richard
> Cochran <richardcochran@gmail.com>
> Cc: Simon Horman <horms@kernel.org>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Ben Shimol, Yedidya <yedidya.ben.shimol@intel.com>;
> Stern, Avraham <avraham.stern@intel.com>; Gabay, Daniel
> <daniel.gabay@intel.com>; Prabhu, Krishnanand
> <krishnanand.prabhu@intel.com>; Coelho, Luciano <luciano.coelho@intel.com>;
> Gregory Greenman <gregory.greenman@intel.com>; stable@vger.kernel.org
> Subject: [PATCH] wifi: iwlwifi: ptp: Fix potential race condition in PTP removal
>
> iwl_mvm_ptp_remove() and iwl_mld_ptp_remove() call
> cancel_delayed_work_sync() only after ptp_clock_unregister() and after partially
> clearing ptp_data state.
>
> This creates a race where the delayed work (iwl_mvm_ptp_work /
> iwl_mld_ptp_work) can run while teardown is in progress and observe a partially
> modified PTP state. In addition, the work may re-arm itself, extending the
> teardown window and risking execution after driver resources have been
> released.
Not sure I understand how is the fact that work re-arm itself is related/makes the bug worse?
>
> Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the
> delayed work is fully stopped before any PTP cleanup begins. This follows the
> standard pattern used by other Intel PTP drivers such as e1000e, igb, ixgbe, and
> ice.
>
> Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
> Fixes: 1595ecce1cf3 ("wifi: iwlwifi: mvm: add support for PTP HW clock (PHC)")
> Cc: stable@vger.kernel.org
> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
> ---
> drivers/net/wireless/intel/iwlwifi/mld/ptp.c | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/ptp.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
> b/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
> index 231920425c06..b40182320801 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
> @@ -319,10 +319,10 @@ void iwl_mld_ptp_remove(struct iwl_mld *mld)
> mld->ptp_data.ptp_clock_info.name,
> ptp_clock_index(mld->ptp_data.ptp_clock));
>
> + cancel_delayed_work_sync(&mld->ptp_data.dwork);
> ptp_clock_unregister(mld->ptp_data.ptp_clock);
> mld->ptp_data.ptp_clock = NULL;
> mld->ptp_data.last_gp2 = 0;
> mld->ptp_data.wrap_counter = 0;
> - cancel_delayed_work_sync(&mld->ptp_data.dwork);
> }
> }
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
> index 1da6260e238c..2b01ca36a1b5 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
> @@ -325,11 +325,11 @@ void iwl_mvm_ptp_remove(struct iwl_mvm *mvm)
> mvm->ptp_data.ptp_clock_info.name,
> ptp_clock_index(mvm->ptp_data.ptp_clock));
>
> + cancel_delayed_work_sync(&mvm->ptp_data.dwork);
> ptp_clock_unregister(mvm->ptp_data.ptp_clock);
> mvm->ptp_data.ptp_clock = NULL;
> memset(&mvm->ptp_data.ptp_clock_info, 0,
> sizeof(mvm->ptp_data.ptp_clock_info));
> mvm->ptp_data.last_gp2 = 0;
> - cancel_delayed_work_sync(&mvm->ptp_data.dwork);
> }
> }
> --
> 2.43.0
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw89: Turbo mode for RTL8851BU/RTL8852BU
From: Ping-Ke Shih @ 2026-02-09 8:29 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <88cce107-ff52-496f-bb77-b930e4182b67@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> RTL8851BU and RTL8852BU currently have much lower TX speed than
> expected, ~100 and ~300 Mbps, respectively. This is because part of the
> chip's memory is allocated for some unknown firmware features instead of
> the TX buffers.
>
> The vendor drivers have a module parameter called "rtw_quota_turbo_en",
> which can be used to choose between full TX speed or the unknown
> firmware features. It is on by default.
>
> Change the relevant chip parameters to implement the turbo mode. Do it
> only for USB because PCI is already fast even without the turbo mode.
> It's unclear if SDIO will need it or not.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
>
> What firmware features are we missing when we use the turbo mode?
> Is it anything important?
I asked experts internally. This change is totally fine and doesn't affect
firmware features. For newer driver, turbo mode (quota) is adopted.
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Ping-Ke Shih @ 2026-02-09 8:19 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <4fc30feb-5616-4e2e-86d8-0d96e4f191c2@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
> NetworkManager?) triggers a scan every five minutes. During these scans
> mac80211 transmits many QoS Null frames in quick succession. Because
> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
> asks the firmware to report the TX ACK status for each of these frames.
> Sometimes the firmware can't process the TX status requests quickly
> enough, they add up, it only processes some of them, and then marks
> every subsequent TX status report with the wrong number.
Does it mean number of reports is correct? But with incorrect sequence number?
Then, you just ignore checking 'sn' but assume 'st' is correct.
>
> The symptom is that after a while the warning "failed to get tx report
> from firmware" appears every five minutes.
>
> This problem apparently happens only with the older RTL8723D, RTL8821A,
> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
> number reported by these chips and match the reports with the requests
> in the order they come in.
>
> Tested with RTL8821AU and RTL8723DU.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> ---
> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> index c04ff31d0f1e..98215ecc884a 100644
> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
> spin_lock_irqsave(&tx_report->q_lock, flags);
> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
> - if (*n == sn) {
> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
Can we only limit to USB devices (or non-PCI devices)?
> __skb_unlink(cur, &tx_report->queue);
> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
> break;
> --
> 2.52.0
^ permalink raw reply
* RE: [PATCH v2 2/3] wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
From: Korenblit, Miriam Rachel @ 2026-02-09 8:01 UTC (permalink / raw)
To: Marco Crivellari, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <20251120100850.66192-3-marco.crivellari@suse.com>
> -----Original Message-----
> From: Marco Crivellari <marco.crivellari@suse.com>
> Sent: Thursday, November 20, 2025 12:09 PM
> To: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Tejun Heo <tj@kernel.org>; Lai Jiangshan <jiangshanlai@gmail.com>; Frederic
> Weisbecker <frederic@kernel.org>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Marco Crivellari <marco.crivellari@suse.com>; Michal
> Hocko <mhocko@suse.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Johannes Berg
> <johannes@sipsolutions.net>
> Subject: [PATCH v2 2/3] wifi: iwlwifi: fw: replace use of system_unbound_wq
> with system_dfl_wq
>
> This patch continues the effort to refactor workqueue APIs, which has begun with
> the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and
> system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen after a careful review and conversion of each individual
> case, workqueue users must be converted to the better named new workqueues
> with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> index 2ce55859641c..e5f31b82339a 100644
> --- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> +++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> @@ -2933,7 +2933,7 @@ int iwl_fw_dbg_collect_desc(struct iwl_fw_runtime
> *fwrt,
> IWL_WARN(fwrt, "Collecting data: trigger %d fired.\n",
> le32_to_cpu(desc->trig_desc.type));
>
> - queue_delayed_work(system_unbound_wq, &wk_data->wk,
> + queue_delayed_work(system_dfl_wq, &wk_data->wk,
> usecs_to_jiffies(delay));
>
> return 0;
> @@ -3237,7 +3237,7 @@ int iwl_fw_dbg_ini_collect(struct iwl_fw_runtime
> *fwrt,
> if (sync)
> iwl_fw_dbg_collect_sync(fwrt, idx);
> else
> - queue_delayed_work(system_unbound_wq,
> + queue_delayed_work(system_dfl_wq,
> &fwrt->dump.wks[idx].wk,
> usecs_to_jiffies(delay));
>
> --
> 2.51.1
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw88: WARN only once in rtw_phy_get_tx_power_limit()
From: Ping-Ke Shih @ 2026-02-09 8:01 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <98129317-7e88-4654-910b-630aa992bfa3@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> This function WARNs when the wifi band, channel number, channel width,
> rate, or RF path are invalid. Two or three people have reported that it
> floods the kernel log with warnings because they try to switch to
> invalid channel numbers, like 130.
>
> One warning is probably enough, so turn WARN into WARN_ONCE.
>
> Closes: https://github.com/lwfinger/rtw88/issues/428
As the issue says "invalid arguments, band=1, bw=2, path=1, rate=83, ch=130",
I think it operates on bandwidth 80MHz and primary channel 130.
But I don't see 20MHz primary channel, for example [1].
Can we stop using this channel at set_channel() ahead to avoid this error?
[1] https://en.wikipedia.org/wiki/List_of_WLAN_channels
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> ---
> drivers/net/wireless/realtek/rtw88/phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
> index e2ac5c6fd500..2a3929561664 100644
> --- a/drivers/net/wireless/realtek/rtw88/phy.c
> +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> @@ -2210,8 +2210,8 @@ static s8 rtw_phy_get_tx_power_limit(struct rtw_dev *rtwdev, u8 band,
> return power_limit;
>
> err:
> - WARN(1, "invalid arguments, band=%d, bw=%d, path=%d, rate=%d, ch=%d\n",
> - band, bw, rf_path, rate, channel);
> + WARN_ONCE(1, "invalid arguments, band=%d, bw=%d, path=%d, rate=%d, ch=%d\n",
> + band, bw, rf_path, rate, channel);
> return (s8)rtwdev->chip->max_power_index;
I feel this will be a problem if max_power_index is adopted.
The power is too high.
> }
>
> --
> 2.52.0
^ permalink raw reply
* RE: [PATCH v2 1/3] wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
From: Korenblit, Miriam Rachel @ 2026-02-09 8:01 UTC (permalink / raw)
To: Marco Crivellari, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <20251120100850.66192-2-marco.crivellari@suse.com>
> -----Original Message-----
> From: Marco Crivellari <marco.crivellari@suse.com>
> Sent: Thursday, November 20, 2025 12:09 PM
> To: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Tejun Heo <tj@kernel.org>; Lai Jiangshan <jiangshanlai@gmail.com>; Frederic
> Weisbecker <frederic@kernel.org>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Marco Crivellari <marco.crivellari@suse.com>; Michal
> Hocko <mhocko@suse.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Johannes Berg
> <johannes@sipsolutions.net>
> Subject: [PATCH v2 1/3] wifi: iwlwifi: replace use of system_unbound_wq with
> system_dfl_wq
>
> This patch continues the effort to refactor workqueue APIs, which has begun with
> the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and
> system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen after a careful review and conversion of each individual
> case, workqueue users must be converted to the better named new workqueues
> with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> index a0cc5d7745e8..7e84074e1a3c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> @@ -1092,7 +1092,7 @@ static inline void iwl_trans_schedule_reset(struct
> iwl_trans *trans,
> */
> trans->restart.during_reset = test_bit(STATUS_IN_SW_RESET,
> &trans->status);
> - queue_delayed_work(system_unbound_wq, &trans->restart.wk, 0);
> + queue_delayed_work(system_dfl_wq, &trans->restart.wk, 0);
> }
>
> static inline void iwl_trans_fw_error(struct iwl_trans *trans,
> --
> 2.51.1
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
^ permalink raw reply
* RE: [PATCH v2 3/3] wifi: iwlwifi: nvm: replace use of system_wq with system_percpu_wq
From: Korenblit, Miriam Rachel @ 2026-02-09 7:58 UTC (permalink / raw)
To: Marco Crivellari, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <20251120100850.66192-4-marco.crivellari@suse.com>
> -----Original Message-----
> From: Marco Crivellari <marco.crivellari@suse.com>
> Sent: Thursday, November 20, 2025 12:09 PM
> To: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Tejun Heo <tj@kernel.org>; Lai Jiangshan <jiangshanlai@gmail.com>; Frederic
> Weisbecker <frederic@kernel.org>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Marco Crivellari <marco.crivellari@suse.com>; Michal
> Hocko <mhocko@suse.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Johannes Berg
> <johannes@sipsolutions.net>
> Subject: [PATCH v2 3/3] wifi: iwlwifi: nvm: replace use of system_wq with
Please change nvm->mvm.
Otherwise looks good to me
> system_percpu_wq
>
> This patch continues the effort to refactor workqueue APIs, which has begun with
> the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and
> system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen after a careful review and conversion of each individual
> case, workqueue users must be converted to the better named new workqueues
> with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> 2.51.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox