kernel/linux.git/net/mac80211/ht.c, branch linux-7.0.y

wifi: mac80211: handle WLAN_HT_ACTION_NOTIFY_CHANWIDTH async

2025-07-15T09:00:39+00:00

If this action frame, with the value of IEEE80211_HT_CHANWIDTH_ANY, arrives right after a beacon that changed the operational bandwidth from 20 MHz to 40 MHz, then updating the rate control bandwidth to 40 can race with updating the chanctx width (that happens in the beacon proccesing) back to 40 MHz: cpu0 cpu1 ieee80211_rx_mgmt_beacon ieee80211_config_bw ieee80211_link_change_chanreq (*)ieee80211_link_update_chanreq ieee80211_rx_h_action (**)ieee80211_sta_cur_vht_bw (***) ieee80211_recalc_chanctx_chantype in (**), the maximum between the capability width and the bss width is returned. But the bss width was just updated to 40 in (*), so the action frame handling code will increase the width of the rate control before the chanctx was increased (in ***), leading to a FW error (at least in iwlwifi driver. But this is wrong regardless). Fix this by simply handling the action frame async, so it won't race with the beacon proccessing. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218632 Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250709233537.bb9dc6f36c35.I39782d6077424e075974c3bee4277761494a1527@changeid Signed-off-by: Johannes Berg

wifi: mac80211: Support EHT 1024 aggregation size in TX

2024-11-12T12:41:45+00:00

Support EHT 1024 aggregation size in TX The 1024 agg size for RX is supported but not for TX. This patch adds this support and refactors common parsing logics for addbaext in both process_addba_resp and process_addba_req into a function. Reviewed-by: Shayne Chen Reviewed-by: Money Wang Co-developed-by: Peter Chiu Signed-off-by: Peter Chiu Signed-off-by: MeiChia Chiu Link: https://patch.msgid.link/20241112083846.32063-1-MeiChia.Chiu@mediatek.com [pass elems/len instead of mgmt/len/is_req] Signed-off-by: Johannes Berg

wifi: mac80211: refactor block ack management code

2024-08-27T08:12:50+00:00

Introduce 'ieee80211_mgmt_ba()' to avoid code duplication between 'ieee80211_send_addba_resp()', 'ieee80211_send_addba_request()', and 'ieee80211_send_delba()', ensure that all related addresses are '__aligned(2)', and prefer convenient 'ether_addr_copy()' over generic 'memcpy()'. No functional changes expected. Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20240725090925.6022-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg

wifi: mac80211: send DelBA with correct BSSID

2024-05-23T09:46:37+00:00

In MLO, the deflink BSSID is clearly invalid. Since we fill the addresses as MLD addresses and translate later, use the AP address here instead. This fixes an issue that happens with HW restart, where the DelBA frame is transmitted, but not processed correctly due to the wrong BSSID (or even just discarded entirely). As a result, the BA sessions are kept alive; however, as other state is reset during HW restart, this then fails (reorder, etc.) and data doesn't go through until new BA sessions are established. Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240510112601.f4e1effdea29.I98e81f22166b68d4b6211191bcaaf8531b324a77@changeid Signed-off-by: Johannes Berg

wifi: mac80211: clarify IEEE80211_STATUS_SUBDATA_MASK

2024-03-25T14:39:28+00:00

We have 13 bits for the status_data, so restricting type to 4 and subdata to 8 bits is confusing, even if we don't need more bits now. Change subdata mask to be 9 bits instead, just to make things match up. If we actually need more types or more subdata bits we can later also reshuffle the bits between these, but we should probably keep them at 13 bits together. Signed-off-by: Johannes Berg Reviewed-by: Ayala Beker Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320091155.28ac7b665039.I1abbb13e90f016cab552492e05f5cb5b52de6463@changeid Signed-off-by: Johannes Berg

wifi: mac80211: introduce 'channel request'

2024-02-08T12:07:34+00:00

For channel contexts, mac80211 currently uses the cfg80211 chandef struct (control channel, center freq(s), width) to define towards drivers and internally how these behave. In fact, there are _two_ such structs used, where the min_def can reduce bandwidth according to the stations connected. Unfortunately, with EHT this is longer be sufficient, at least not for all hardware. EHT requires that non-AP STAs that are connected to an AP with a lower bandwidth than it (the AP) advertises (e.g. 160 MHz STA connected to 320 MHz AP) still be able to receive downlink OFDMA and respond to trigger frames for uplink OFDMA that specify the position and bandwidth for the non-AP STA relative to the channel the AP is using. Therefore, they need to be aware of this, and at least for some hardware (e.g. Intel) this awareness is in the hardware. As a result, use of the "same" channel may need to be split over two channel contexts where they differ by the AP being used. As a first step, introduce a concept of a channel request ('chanreq') for each interface, to control the context it requests. This step does nothing but reorganise the code, so that later the AP's chandef can be added to the request in order to handle the EHT case described above. Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid Signed-off-by: Johannes Berg

wifi: mac80211: trace SMPS requests from driver

2024-02-02T13:20:42+00:00

Even if there are a lot of possible ways drivers might call this, at least knowing when they do and with what settings can be useful. Add tracing for it. Link: https://msgid.link/20240129195435.b20d2ead2013.I8213e65c274451d523a3397519ac578c3ed2df4d@changeid [removed link-id contortions as suggested by Jeff] Signed-off-by: Johannes Berg

wifi: mac80211: handle 320 MHz in ieee80211_ht_cap_ie_to_sta_ht_cap

2023-11-24T17:42:18+00:00

The new 320 MHz channel width wasn't handled, so connecting a station to a 320 MHz AP would limit the station to 20 MHz (on HT) after a warning, handle 320 MHz to fix that. Signed-off-by: Ben Greear Link: https://lore.kernel.org/r/20231109182201.495381-1-greearb@candelatech.com [write a proper commit message] Signed-off-by: Johannes Berg

wifi: mac80211: remove ampdu_mlme.mtx

2023-09-11T09:27:22+00:00

We now hold the wiphy mutex everywhere that we use or needed the A-MPDU locking, so we don't need this mutex any more. Remove it. Most of this change was done automatically with spatch. Signed-off-by: Johannes Berg

wifi: mac80211: convert A-MPDU work to wiphy work

2023-09-11T09:27:19+00:00

Convert the A-MPDU work to wiphy work so it holds the wiphy mutex and we can later guarantee that to drivers. It might seem that we could run these concurrently for different stations, but they're all on the ordered mac80211 workqueue, so this shouldn't matter for that. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg