summaryrefslogtreecommitdiff
path: root/net/mac80211/tx.c
AgeCommit message (Collapse)AuthorFilesLines
2026-08-02wifi: mac80211: skip unused probe response countdown offsetsZhao Li1-1/+2
mac80211 copies cfg80211's variable-length countdown offset list into a zero-initialized fixed-size array, leaving unused entries at zero. The beacon branch already skips those zero entries, but the AP probe-response branch writes through them unconditionally. When a probe-response template has no countdown offset, the write through an unused zero entry overwrites resp->data[0], corrupting the first byte of the template. cfg80211 already bounds explicitly supplied non-zero offsets in nl80211_parse_counter_offsets(), so this is a zero-sentinel bug, not an out-of-bounds write. Skip zero probe-response offsets, matching the beacon path. Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp") Link: https://lore.kernel.org/all/20260708195911.84365-6-enderaoelyther@gmail.com/ Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260723011001.76851-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: cfg80211: convert tx_control_port cookie to input parameterArend van Spriel1-14/+13
The tx_control_port op was excluded from the previous commit because a NULL cookie was affecting different behavior, ie. signalling that no TX status is wanted. Since cfg80211_assign_cookie() guarantees a non-zero value, cookie value 0 can be used instead. So pass 0 when dont_wait_for_ack is set, otherwise pass value returned from cfg80211_assign_cookie() call. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-13-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: mac80211: stop using ieee80211_mgmt_tx_cookie()Arend van Spriel1-3/+1
Now that cfg80211 pre-assigns the cookie before calling into mac80211, stop calling ieee80211_mgmt_tx_cookie() in all affected paths: - ieee80211_start_roc_work(): for normal ROC use the pre-assigned value directly instead of generating a new one. - ieee80211_attach_ack_skb(): the cookie is already set by the caller; remove the ieee80211_mgmt_tx_cookie() call and store it in the ack SKB as-is. This covers both mgmt_tx and probe_peer since both call ieee80211_attach_ack_skb(). - ieee80211_mgmt_tx(): the dummy 0xffffffff assignment for the dont_wait_for_ack case is no longer needed; cfg80211_assign_cookie() guarantees a non-zero value which is sufficient for the internal ROC vs mgmt-tx distinction. - ieee80211_store_ack_skb(): same fix for the tx_control_port path. With no remaining callers, remove ieee80211_mgmt_tx_cookie() and the roc_cookie_counter field from struct ieee80211_local. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-3-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02Revert "wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) frames"Johannes Berg1-3/+0
This reverts commit dd406779999fa2065ec6b7c4f80906b727041d2c. Never encrypting the frames broke a number of tests that do additional pre-authentication while already connected, and then the frames didn't go out correctly. Whatever this was intended to fix, this wasn't the right fix. Fixes: dd406779999f ("wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) frames") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-28wifi: mac80211: add ieee80211_txq_aql_pending()Felix Fietkau1-0/+18
Add a function to allow drivers to query the pending AQL airtime for a given txq, for both unicast and broadcast. This will be used for mt76 to limit buffering in AP mode for power-save stations. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260724115429.3921457-4-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-28wifi: mac80211: add AQL support for multicast packetsFelix Fietkau1-24/+28
Excessive multicast traffic with little competing unicast traffic can easily flood hardware queues, leading to throughput issues. Additionally, filling the hardware queues with too many packets breaks FQ for multicast data. Fix this by enabling AQL for multicast packets. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260724115429.3921457-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-27Merge tag 'wireless-2026-07-26' of ↵Jakub Kicinski1-0/+10
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless-next-2026-07-26 Mostly driver changes this time: - new driver mm81x for an S1G device - new driver nxpwifi for NXP devices (mostly forked off from mwifiex) - ath12k: much kernel infrastructure integration work - brcmfmac: DPP support, some Cypress part update - nl80211: per-link statistics support ==================== Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: mac80211: don't encrypt pre-auth (ETH_P_PREAUTH) framesDeepanshu Kartikey1-0/+3
Pre-authentication frames (ETH_P_PREAUTH, 0x88C7) are sent before the authentication handshake completes with the target AP, so no encryption key exists for them yet. Unlike normal EAPOL frames (ETH_P_8021X, 0x888E) which are registered as the control port protocol, pre-auth frames are not recognized as control port frames, causing the kernel to incorrectly assign the current AP's key and attempt encryption, resulting in a WARN_ON in ieee80211_encrypt_tx_skb when the cipher is not handled. Fix this by setting IEEE80211_TX_INTFL_DONT_ENCRYPT for pre-auth frames in ieee80211_tx_h_check_control_port_protocol(), so that key selection skips them and they are sent unencrypted as intended. Note that the only driver hitting this path is hwsim. Reported-by: syzbot+b6ce23950fd636e6efb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6ce23950fd636e6efb6 Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260713015946.44636-1-kartikey406@gmail.com [add note about hwsim, fix subject] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-07wifi: mac80211: Route (Re)association req/response to per-STA queueIlan Peer1-0/+7
An association request or response frame is generally delivered to the driver without a TX queue object. However, with drivers that do encryption offload and couple the key with a transmit queue, this means that the frames are not being encrypted. Fix this by routing the association frames to the management TXQ. This will allow the driver to set up the required resources before transmitting the association frame, e.g., set up keys etc. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260706222925.febcc62f485c.Iff932880e4b98232cbf6ba405fbb90d650a85381@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-06wifi: mac80211: free ack status frame on TX header build failureZhiling Zou1-1/+16
ieee80211_build_hdr() stores an ACK status frame before it has finished all validation and header construction. If a later error path is taken, the transmit skb is freed but the stored ACK status frame remains in local->ack_status_frames. This can happen for control port frames when the requested MLO link ID does not match the link selected for a non-MLO station. Repeated failures can fill the ACK status IDR and leave pending ACK frames until hardware teardown. Remove any stored ACK status frame before returning an error after it has been inserted into the IDR. Fixes: a729cff8ad51 ("mac80211: implement wifi TX status") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Link: https://patch.msgid.link/9de0423da840e92084915b8f92e66a421245c4b8.1782462409.git.roxy520tt@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10Merge tag 'wireless-next-2026-06-10' of ↵Jakub Kicinski1-20/+91
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a few last updates, notably: - b43: new support for an 11n device - mt76: - mt792x broken usb transport detection - mt7921 regd improvements - mt7927 support - iwlwifi: - more kunit tests - FW version updates - ath12k: WDS support - rtw89: - RTL8922AU support - USB 3 mode switch for performance - better monitor radiotap support - RTL8922DE preparations - cfg80211/mac80211: - update UHR to D1.4, UHR DBE support - finally remove 5/10 MHz support - S1G rate reporting - multicast encapsulation offload * tag 'wireless-next-2026-06-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (285 commits) b43: add RF power offset for N-PHY r8 + radio 2057 r8 b43: add channel info table for N-PHY r8 + radio 2057 r8 b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8 b43: support radio 2057 rev 8 b43: route d11 corerev 22 to 24-bit indirect radio access b43: add d11 core revision 0x16 to id table b43: add firmware mappings for rev22 rfkill: Replace strcpy() with memcpy() wifi: brcmfmac: flowring: simplify flow allocation wifi: brcm80211: change current_bss to value wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits wifi: ath: Update copyright in testmode_i.h wifi: ath10k: Update Qualcomm copyrights wifi: ath11k: Update Qualcomm copyrights wifi: ath12k: Update Qualcomm copyrights wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks wifi: mt76: mt7921: assert sniffer on chanctx change wifi: mt76: mt7996: fix potential tx_retries underflow wifi: mt76: mt7925: fix potential tx_retries underflow ... ==================== Link: https://patch.msgid.link/20260610103637.179340-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05wifi: mac80211: Add 802.3 multicast encapsulation offload supportTamizh Chelvam Raja1-7/+44
mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add multicast to unicast support for 802.3 pathTamizh Chelvam Raja1-7/+26
mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit()Tamizh Chelvam Raja1-4/+9
Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-1/+3
Cross-merge networking fixes after downstream PR (net-7.1-rc7). Silent conflicts: net/wireless/nl80211.c cb9959ab5f99 ("wifi: cfg80211: enforce HE/EHT cap/oper consistency") a384ae969902 ("wifi: cfg80211: move AP HT/VHT/... operation to beacon info") https://lore.kernel.org/aiGJDaHV4UlCexIQ@sirena.org.uk Conflicts: drivers/net/wireless/intel/iwlwifi/mld/ap.c a342c99cb70d ("wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED") 9bf1b409afc7 ("wifi: iwlwifi: mld: send tx power constraints before link activation") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk drivers/net/wireless/intel/iwlwifi/pcie/drv.c 093305d801fa ("wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used") e2323929a68a ("wifi: iwlwifi: pcie: add debug print for resume flow if powered off") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk Adjacent changes: drivers/net/ethernet/airoha/airoha_eth.c b38cae85d1c4 ("net: airoha: Fix use-after-free in metadata dst teardown") ec6c391bcca7 ("net: airoha: Introduce airoha_gdm_dev struct") drivers/net/ethernet/microchip/lan743x_main.c 8173d22b211f ("net: lan743x: permit VLAN-tagged packets up to configured MTU") e3c6508a46f5 ("net: lan743x: avoid netdev-based logging before netdev registration") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04wifi: mac80211: fix monitor mode frame capture for real chanctx drivers傅继晗1-2/+12
Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection behaviour") restored the monitor injection fallback for drivers using chanctx emulation but explicitly deferred drivers that transitioned to real chanctx ops. mt76 falls in that category and still drops every injected frame when monitor coexists with another interface. When the monitor has no chanctx of its own, fall back to the only chanctx in flight if there is exactly one. Refuse if multiple are present: picking arbitrarily would inject on an unrelated channel. Emulated and real chanctx drivers both flow through this fallback, since emulation always presents zero or one chanctx in local->chanctx_list. Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor VIF on the same phy + aireplay-ng deauth from the monitor) on mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a Kali VM with MT7921U passthrough as the closest match to the original reporter's setup. None reproduced the hang seen against the earlier attempt at this fix (<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1 on lore in March. Cc: <stable+noautosel@kernel.org> # causes some older drivers to crash Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com> Closes: https://github.com/morrownr/USB-WiFi/issues/682 Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by: 傅继晗 <fjhhz1997@gmail.com> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/5c2760bd9bc34616bf7892848872522254dd1ce5.1780513445.git.lucid_duck@justthetip.ca Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-02wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotapDeepanshu Kartikey1-1/+3
When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: info->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds. Reported-by: syzbot+8e0622f6d9446420271f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8e0622f6d9446420271f Fixes: ef246a1480cc ("wifi: mac80211: support antenna control in injection") Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260531011721.102941-1-kartikey406@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-05wifi: mac80211: Fix a kernel panic in ieee80211_encrypt_tx_skb()Andrei Otcheretianski1-2/+9
skb->dev may be NULL for frames on non-netdev devices. For example, NAN device frames after pairing. Fix it. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260504072055.1292999-2-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-05wifi: mac80211: allow userspace TX/RX over NAN Data interfacesIlan Peer1-2/+3
Allow TX/RX of action frames (for NAN action frames) over NAN Data interfaces to support cases where there's a secure NDP and NAFs may be exchanged over that. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260504101829.4ac207c60ebb.Ic4b1c90552497b7ff2616651a408e5fe8bde7b99@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-05wifi: mac80211: track the id of the NAN cluster we joinedMiri Korenblit1-1/+1
Currently, we store in nan.conf the cluster id that was configured from upper layer to be used when the device opens a cluster. But after we joined a cluster, the configured cluster id is no longer relevant. Particularly, in reconfig we will give the driver the (possibly) wrong cluster id. Add an API to be called by the driver when joined a cluster in which the cluster id will be updated. Use the locally stored cluster id instead of cfg80211's copy. Ignore cluster id updates from cfg80211 if we already have one configured. Adjust the drivers that use the cfg80211 API (cfg80211_nan_cluster_joined) directly, otherwise we break functionality (i.e. accept frame check won't evaluate to true). Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260504101829.5dada1b756a4.I0f1060215267fd8aef31afd99f8f42e6fde7f234@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-28wifi: mac80211: always allow transmitting null-data on TXQsJohannes Berg1-1/+1
Jouni reported that certain sequences of tests caused some WDS tests to fail after applying the upcoming hwsim changes for NAN. I bisected that down to converting hwsim to TXQs, and after a long debug session found that the 4-addr NDP was getting dropped, because it goes out via a (management) TXQ and is a data frame. It's unclear to me now why this only happens in some test sequences (e.g. "sigma_dut_sae_h2e_ap_loop ap_wds_sta" and "sigma_dut_eap_ttls_all_akm_suites ap_wds_sta_open"), maybe that affects timing and the frame is otherwise delayed in some way. Correct the check to only drop frames that actually carry data, not NDPs. Reported-by: Jouni Malinen <j@w1.fi> Link: https://patch.msgid.link/20260417141601.851ddf4adb59.I3d668c0e1bdca9cd98f2fc46f84a066e68cc7a62@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-07wifi: mac80211: add support for TX over NAN_DATA interfacesMiri Korenblit1-3/+29
Add support for TXing frames over NAN_DATA interfaces: - find the NDI station - populoate the addresses fields - use NUM_NL80211_BANDS for the band, similar to NAN interfaces. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260326121156.b1d248947158.I04b27d9727f7a553fa80520cf6e532683ac03690@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-07wifi: mac80211: add a TXQ for management frames on NAN devicesBenjamin Berg1-4/+16
Currently there is no TXQ for non-data frames. Add a new txq_mgmt for this purpose and create one of these on NAN devices. On NAN devices, these frames may only be transmitted during the discovery window and it is therefore helpful to schedule them using a queue. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260326121156.32eddd986bd2.Iee95758287c276155fbd7779d3f263339308e083@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-1/+3
Cross-merge networking fixes after downstream PR (net-7.0-rc5). net/netfilter/nft_set_rbtree.c 598adea720b97 ("netfilter: revert nft_set_rbtree: validate open interval overlap") 3aea466a43998 ("netfilter: nft_set_rbtree: don't disable bh when acquiring tree lock") https://lore.kernel.org/abgaQBpeGstdN4oq@sirena.org.uk No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-18wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failureFelix Fietkau1-1/+3
ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260314065455.2462900-1-nbd@nbd.name Fixes: 06be6b149f7e ("mac80211: add ieee80211_tx_prepare_skb() helper function") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: update outdated commentKexin Sun1-4/+1
The function ieee80211_start_scan() was refactored and replaced by __ieee80211_start_scan() in commit f3b85252f081 ("mac80211: fix scan races and rework scanning"). Update the comment in ieee80211_tx_h_check_assoc() accordingly. Additionally, remove the broken gmane.org link in the comment. Suggested-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Suggested-by: Johannes Berg <johannes@sipsolutions.net> Assisted-by: unnamed:deepseek-v3.2 coccinelle Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn> Link: https://patch.msgid.link/20260228061944.887-1-kexinsun@smail.nju.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: Fix AAD/Nonce computation for management frames with MLOSai Pratyusha Magam1-0/+32
Per IEEE Std 802.11be-2024, 12.5.2.3.3, if the MPDU is an individually addressed Data frame between an AP MLD and a non-AP MLD associated with the AP MLD, then A1/A2/A3 will be MLD MAC addresses. Otherwise, Al/A2/A3 will be over-the-air link MAC addresses. Currently, during AAD and Nonce computation for software based encryption/decryption cases, mac80211 directly uses the addresses it receives in the skb frame header. However, after the first authentication, management frame addresses for non-AP MLD stations are translated to MLD addresses from over the air link addresses in software. This means that the skb header could contain translated MLD addresses, which when used as is, can lead to incorrect AAD/Nonce computation. In the following manner, ensure that the right set of addresses are used: In the receive path, stash the pre-translated link addresses in ieee80211_rx_data and use them for the AAD/Nonce computations when required. In the transmit path, offload the encryption for a CCMP/GCMP key to the hwsim driver that can then ensure that encryption and hence the AAD/Nonce computations are performed on the frame containing the right set of addresses, i.e, MLD addresses if unicast data frame and link addresses otherwise. To do so, register the set key handler in hwsim driver so mac80211 is aware that it is the driver that would take care of encrypting the frame. Offload encryption for a CCMP/GCMP key, while keeping the encryption for WEP/TKIP and MMIE generation for a AES_CMAC or a AES_GMAC key still at the SW crypto in mac layer Co-developed-by: Rohan Dutta <quic_drohan@quicinc.com> Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com> Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Link: https://patch.msgid.link/20260226042959.3766157-1-sai.magam@oss.qualcomm.com [only store and apply link_addrs for unicast non-data rather storing always and applying for !unicast_data] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: fetch unsolicited probe response template by link IDSriram R1-7/+13
Currently, the unsolicited probe response template is always fetched from the default link of a virtual interface in both Multi-Link Operation (MLO) and non-MLO cases. However, in the MLO case there is a need to fetch the unsolicited probe response template from a specific link instead of the default link. Hence, add support for fetching the unsolicited probe response template based on the link ID from the corresponding link data. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-2-a2746a853f75@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: fetch FILS discovery template by link IDSriram R1-7/+13
Currently, the FILS discovery template is always fetched from the default link of a virtual interface in both Multi-Link Operation (MLO) and non-MLO cases. However, in the MLO case there is a need to fetch the FILS discovery template from a specific link instead of the default link. Hence, add support for fetching the FILS discovery template based on the link ID from the corresponding link data. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-1-a2746a853f75@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds1-1/+1
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook1-4/+2
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14wifi: mac80211: add support for encryption/decryption of (Re)Association framesKavita Kavita1-1/+3
Currently, mac80211 does not encrypt or decrypt (Re)Association frames (Request and Response) because temporal keys are not yet available at that stage. With extensions from IEEE P802.11bi, e.g. EPPKE, temporal keys can be established before association. This enables the encryption and decryption of (Re)Association Request/Response frames. Add support to unset the IEEE80211_TX_INTFL_DONT_ENCRYPT flag when the peer is marked as an Enhanced Privacy Protection (EPP) peer and encryption keys are available for the connection in non-AP STA mode, allowing secure transmission of (Re)Association Request frames. Drop unprotected (Re)Association Request/Response frames received from an EPP peer. Co-developed-by: Sai Pratyusha Magam <quic_smagam@quicinc.com> Signed-off-by: Sai Pratyusha Magam <quic_smagam@quicinc.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-9-kavita.kavita@oss.qualcomm.com [remove useless parentheses] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-08wifi: mac80211: restore non-chanctx injection behaviourJohannes Berg1-0/+2
During the transition to use channel contexts throughout, the ability to do injection while in monitor mode concurrent with another interface was lost, since the (virtual) monitor won't have a chanctx assigned in this scenario. It's harder to fix drivers that actually transitioned to using channel contexts themselves, such as mt76, but it's easy to do those that are (still) just using the emulation. Do that. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=218763 Reported-and-tested-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Link: https://patch.msgid.link/20251216105242.18366-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-20wifi: mac80211: refactor CMAC packet handlersChien Wong1-2/+4
Merge CMAC-128 and CMAC-256 handlers since they are almost the same. This removes duplication. The comment 'MIC = AES-128-CMAC(IGTK, AAD ...' is out-dated since CMAC is also used with BIGTK, as is the comment for CMAC-256. Simply remove the comments. Tested-on: mac80211_hwsim Signed-off-by: Chien Wong <m@xv97.com> Link: https://patch.msgid.link/20251113140511.48658-6-m@xv97.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: remove tx_handlers_drop debugfs statsSarika Sharma1-2/+0
Commit 906a5a8c7152 ("wifi: mac80211: add tx_handlers_drop statistics to ethtool") added a tx_handlers_drop counter to ethtool stats. During review [1], Johannes noted that the existing debugfs counter is now redundant. Remove the debugfs stat to avoid duplication and streamline statistics reporting. Link: https://lore.kernel.org/linux-wireless/ce5f2bd899caa2de32f36ce554d9cada073979c0.camel@sipsolutions.net/ # [1] Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250918040846.4032734-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: Support Tx of action frame for NANIlan Peer1-2/+10
Add support for sending management frame over a NAN Device interface: - Declare support for the supported management frames types. - Since action frame transmissions over a NAN Device interface do not necessarily require a channel configuration, e.g., they can be transmitted during DW, modify the Tx path to avoid accessing channel information for NAN Device interface. - In addition modify the points in the Tx path logic to account for cases that a band is not specified in the Tx information. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.23b160089228.I65a58af753bcbcfb5c4ad8ef372d546f889725ba@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-10wifi: mac80211: add tx_handlers_drop statistics to ethtoolSarika Sharma1-1/+6
Currently tx_handlers_drop statistics are handled only for slow TX path and only at radio level. This also requires CONFIG_MAC80211_DEBUG_COUNTERS to be enabled to account the dropped packets. There is no way to check these stats for fast TX, at interface level and monitor without enabling the debug configuration. Hence, add a new counter at the sdata level to track packets dropped with reason as TX_DROP during transmission for fast path, slow path and other tx management packets. Expose this via ethtool statistics, to improve visibility into transmission failures at interface level and aid debugging and performance monitoring. Place the counter in ethtool with other available tx_* stats for better readability and accurate tracking. Sample output: root@buildroot:~# ethtool -S wlan0 NIC statistics: rx_packets: 5904 rx_bytes: 508122 rx_duplicates: 12 rx_fragments: 5900 rx_dropped: 12 tx_packets: 391487 tx_bytes: 600423383 tx_filtered: 0 tx_retry_failed: 10332 tx_retries: 1548 tx_handlers_drop: 4 .... Co-developed-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250822052110.513804-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: support block bitmap S1G TIM encodingLachlan Hodges1-39/+127
An S1G TIM PVB is encoded differently compared to a non-s1g TIM PVB. As the AP dictates which encoding mode it uses, here we only implement block bitmap encoding. This is the default encoding mode used by all current vendor implementations. Additionally, S1G has a maximum AID count of 8192, however we are limiting the current implementation to 1600. This has no resemblence to the standard and is purely an implementation detail. The reason for this is due to the TIM elements maximum length of 255. This allows for, at most, 25 encoded blocks for a PVB encoded with block bitmap. Support for the maximum of 8192 AIDs will require an implementation of page slicing to be added to mac80211. As a result, we perform extra validation on both the STA and AP side when receiving an AID as an S1G interface. Add support for block bitmap encoding for an S1G AP and limit the maximum AID count to 1600 for the current mac80211 implementations. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250725132221.258217-2-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18Reapply "wifi: mac80211: Update skb's control block key in ↵Remi Pommarel1-0/+1
ieee80211_tx_dequeue()" This reverts commit 0937cb5f345c ("Revert "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()""). This commit broke TX with 802.11 encapsulation HW offloading, now that this is fixed, reapply it. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/66b8fc39fb0194fa06c9ca7eeb6ffe0118dcb3ec.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key()Remi Pommarel1-0/+6
With 802.11 encapsulation offloading, ieee80211_tx_h_select_key() is called on 802.3 frames. In that case do not try to use skb data as valid 802.11 headers. Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/linux-wireless/20250410215527.3001-1-spasswolf@web.de Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/1af4b5b903a5fca5ebe67333d5854f93b2be5abe.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Don't call fq_flow_idx() for management framesAlexander Wetzel1-1/+2
skb_get_hash() can only be used when the skb is linked to a netdev device. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames") Link: https://patch.msgid.link/20250717162547.94582-3-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Do not schedule stopped TXQsAlexander Wetzel1-1/+3
Ignore TXQs with the flag IEEE80211_TXQ_STOP when scheduling a queue. The flag is only set after all fragments have been dequeued and won't allow dequeueing other frames as long as the flag is set. For drivers using ieee80211_txq_schedule_start() this prevents an loop trying to push the queued frames while IEEE80211_TXQ_STOP is set: After setting IEEE80211_TXQ_STOP the driver will call ieee80211_return_txq(). Which calls __ieee80211_schedule_txq(), detects that there sill are frames in the queue and immediately restarts the stopped TXQ. Which can't dequeue any frame and thus starts over the loop. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Link: https://patch.msgid.link/20250717162547.94582-2-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support returning the S1G short beacon skbLachlan Hodges1-11/+84
When short beaconing is enabled, check the value of the sb_count to determine whether we are to send a long beacon or short beacon. sb_count represents the number of short beacons until the next long beacon, where if its value is 0 we are to send a long beacon. The value is then reset to the long beacon period, which represents the number of beacon intervals between each long beacon. The decrement process follows the same cadence as the decrement of the DTIM count value. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-5-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-24wifi: mac80211: add support for S1G aggregationLachlan Hodges1-1/+2
Allow an S1G station to use aggregation. Signed-off-by: Sophronia Koilpillai <sophronia.koilpillai@morsemicro.com> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250617080610.756048-5-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-24wifi: cfg80211/mac80211: Add support to get radio indexRoopni Devanathan1-2/+2
Currently, per-radio attributes are set on per-phy basis, i.e., all the radios present in a wiphy will take attributes values sent from user. But each radio in a wiphy can get different values from userspace based on its requirement. To extend support to set per-radio attributes, add support to get radio index from userspace. Add an NL attribute - NL80211_ATTR_WIPHY_RADIO_INDEX, to get user specified radio index for which attributes should be changed. Pass this to individual drivers, so that the drivers can use this radio index to change per-radio attributes when necessary. Currently, per-radio attributes identified are: NL80211_ATTR_WIPHY_TX_POWER_LEVEL NL80211_ATTR_WIPHY_ANTENNA_TX NL80211_ATTR_WIPHY_ANTENNA_RX NL80211_ATTR_WIPHY_RETRY_SHORT NL80211_ATTR_WIPHY_RETRY_LONG NL80211_ATTR_WIPHY_FRAG_THRESHOLD NL80211_ATTR_WIPHY_RTS_THRESHOLD NL80211_ATTR_WIPHY_COVERAGE_CLASS NL80211_ATTR_TXQ_LIMIT NL80211_ATTR_TXQ_MEMORY_LIMIT NL80211_ATTR_TXQ_QUANTUM By default, the radio index is set to -1. This means the attribute should be treated as a global configuration. If the user has not specified any index, then the radio index passed to individual drivers would be -1. This would indicate that the attribute applies to all radios in that wiphy. Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com> Link: https://patch.msgid.link/20250615082312.619639-2-quic_rdevanat@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-17wifi: mac80211: don't WARN for late channel/color switchJohannes Berg1-8/+21
There's really no value in the WARN stack trace etc., the reason for this happening isn't directly related to the calling function anyway. Also, syzbot has been observing it constantly, and there's no way we can resolve it there - those systems are just slow. Instead print an error message (once) and add a comment about what really causes this message. Reported-by: syzbot+468656785707b0e995df@syzkaller.appspotmail.com Reported-by: syzbot+18c783c5cf6a781e3e2c@syzkaller.appspotmail.com Reported-by: syzbot+d5924d5cffddfccab68e@syzkaller.appspotmail.com Reported-by: syzbot+7d73d99525d1ff7752ef@syzkaller.appspotmail.com Reported-by: syzbot+8e6e002c74d1927edaf5@syzkaller.appspotmail.com Reported-by: syzbot+97254a3b10c541879a65@syzkaller.appspotmail.com Reported-by: syzbot+dfd1fd46a1960ad9c6ec@syzkaller.appspotmail.com Reported-by: syzbot+85e0b8d12d9ca877d806@syzkaller.appspotmail.com Link: https://patch.msgid.link/20250617104902.146e10919be1.I85f352ca4a2dce6f556e5ff45ceaa5f3769cb5ce@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-21wifi: check if socket flags are validBert Karwatzki1-3/+3
Checking the SOCK_WIFI_STATUS flag bit in sk_flags may give wrong results since sk_flags are part of a union and the union is used otherwise. Add sk_requests_wifi_status() which checks if sk is non-NULL, sk is a full socket (so flags are valid) and checks the flag bit. Fixes: 76a853f86c97 ("wifi: free SKBTX_WIFI_STATUS skb tx_flags flag") Suggested-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Bert Karwatzki <spasswolf@web.de> Reviewed-by: Jason Xing <kerneljasonxing@gmail.com> Link: https://patch.msgid.link/20250520223430.6875-1-spasswolf@web.de [edit commit message, fix indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mac80211: VLAN traffic in multicast pathMuna Sinada1-2/+4
Currently for MLO, sending out multicast frames on each link is handled by mac80211 only when IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX flag is not set. Dynamic VLAN multicast traffic utilizes software encryption. Due to this, mac80211 should handle transmitting multicast frames on all links for multicast VLAN traffic. Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com> Link: https://patch.msgid.link/20250325213125.1509362-4-muna.sinada@oss.qualcomm.com [remove unnecessary parentheses] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23Revert "mac80211: Dynamically set CoDel parameters per station"Toke Høiland-Jørgensen1-8/+1
This reverts commit 484a54c2e597dbc4ace79c1687022282905afba0. The CoDel parameter change essentially disables CoDel on slow stations, with some questionable assumptions, as Dave pointed out in [0]. Quoting from there: But here are my pithy comments as to why this part of mac80211 is so wrong... static void sta_update_codel_params(struct sta_info *sta, u32 thr) { - if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { 1) sta->local->num_sta is the number of associated, rather than active, stations. "Active" stations in the last 50ms or so, might have been a better thing to use, but as most people have far more than that associated, we end up with really lousy codel parameters, all the time. Mistake numero uno! 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016. - sta->cparams.target = MS2TIME(50); This, by itself, was probably not too bad. 30ms might have been better, at the time, when we were battling powersave etc, but 20ms was enough, really, to cover most scenarios, even where we had low rate 2Ghz multicast to cope with. Even then, codel has a hard time finding any sane drop rate at all, with a target this high. - sta->cparams.interval = MS2TIME(300); But this was horrible, a total mistake, that is leading to codel being completely ineffective in almost any scenario on clients or APS. 100ms, even 80ms, here, would be vastly better than this insanity. I'm seeing 5+seconds of delay accumulated in a bunch of otherwise happily fq-ing APs.... 100ms of observed jitter during a flow is enough. Certainly (in 2016) there were interactions with powersave that I did not understand, and still don't, but if you are transmitting in the first place, powersave shouldn't be a problemmmm..... - sta->cparams.ecn = false; At the time we were pretty nervous about ecn, I'm kind of sanguine about it now, and reliably indicating ecn seems better than turning it off for any reason. [...] In production, on p2p wireless, I've had 8ms and 80ms for target and interval for years now, and it works great. I think Dave's arguments above are basically sound on the face of it, and various experimentation with tighter CoDel parameters in the OpenWrt community have show promising results[1]. So I don't think there's any reason to keep this parameter fiddling; hence this revert. [0] https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/ [1] https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/130 Suggested-By: Dave Taht <dave.taht@gmail.com> In-memory-of: Dave Taht <dave.taht@gmail.com> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: cfg80211/mac80211: remove more 5/10 MHz codeJohannes Berg1-11/+0
We still have ieee80211_chandef_rate_flags() and all that, but all the users seem pretty much broken (deflink, etc.) Remove all the code. It's been two years since last anyone even vaguely entertained the notion of looking at this and fixing it. Link: https://patch.msgid.link/20250329221419.c31da7ae8c84.I1a3a4b6008134d66ca75a5bdfc004f4594da8145@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-13 08:45:19 +0000