kernel/linux.git/include/net/mac80211.h, branch v6.12.35

Revert "mac80211: Dynamically set CoDel parameters per station"

2025-06-27T10:11:33+00:00

[ Upstream commit 4876376988081d636a4c4e5f03a5556386b49087 ] 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 In-memory-of: Dave Taht Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: set ieee80211_prep_tx_info::link_id upon Auth Rx

2025-05-29T09:02:56+00:00

[ Upstream commit 8c60179b64434894eac1ffab7396bac131bc8b6e ] This will be used by the low level driver. Note that link_id will be 0 in case of a non-MLO authentication. Also fix a call-site of mgd_prepare_tx() where the link_id was not populated. Update the documentation to reflect the current state ieee80211_prep_tx_info::link_id is also available in mgd_complete_tx(). Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205110958.6a590f189ce5.I1fc5c0da26b143f5b07191eb592f01f7083d55ae@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: add strict mode disabling workarounds

2025-04-20T08:15:17+00:00

[ Upstream commit 3ad4fce66e4f9d82abfc366707757e29cc14a9d2 ] Add a strict mode where we disable certain workarounds and have additional checks such as, for now, that VHT capabilities from association response match those from beacon/probe response. We can extend the checks in the future. Make it an opt-in setting by the driver so it can be set there in some driver-specific way, for example. Also allow setting this one hw flag through the hwflags debugfs, by writing a new strict=0 or strict=1 value. Signed-off-by: Johannes Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205110958.5cecb0469479.I4a69617dc60ba0d6308416ffbc3102cfd08ba068@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: fix a queue stall in certain cases of CSA

2024-12-19T17:13:10+00:00

[ Upstream commit 11ac0d7c3b5ba58232fb7dacb54371cbe75ec183 ] If we got an unprotected action frame with CSA and then we heard the beacon with the CSA IE, we'll block the queues with the CSA reason twice. Since this reason is refcounted, we won't wake up the queues since we wake them up only once and the ref count will never reach 0. This led to blocked queues that prevented any activity (even disconnection wouldn't reset the queue state and the only way to recover would be to reload the kernel module. Fix this by not refcounting the CSA reason. It becomes now pointless to maintain the csa_blocked_queues state. Remove it. Signed-off-by: Emmanuel Grumbach Fixes: 414e090bc41d ("wifi: mac80211: restrict public action ECSA frame handling") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219447 Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241119173108.5ea90828c2cc.I4f89e58572fb71ae48e47a81e74595cac410fbac@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

move asm/unaligned.h to linux/unaligned.h

2024-10-02T21:23:23+00:00

asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h

wifi: mac80211: handle ieee80211_radar_detected() for MLO

2024-09-06T11:01:05+00:00

Currently DFS works under assumption there could be only one channel context in the hardware. Hence, drivers just calls the function ieee80211_radar_detected() passing the hardware structure. However, with MLO, this obviously will not work since number of channel contexts will be more than one and hence drivers would need to pass the channel information as well on which the radar is detected. Also, when radar is detected in one of the links, other link's CAC should not be cancelled. Hence, in order to support DFS with MLO, do the following changes - * Add channel context conf pointer as an argument to the function ieee80211_radar_detected(). During MLO, drivers would have to pass on which channel context conf radar is detected. Otherwise, drivers could just pass NULL. * ieee80211_radar_detected() will iterate over all channel contexts present and * if channel context conf is passed, only mark that as radar detected * if NULL is passed, then mark all channel contexts as radar detected * Then as usual, schedule the radar detected work. * In the worker, go over all the contexts again and for all such context which is marked with radar detected, cancel the ongoing CAC by calling ieee80211_dfs_cac_cancel() and then notify cfg80211 via cfg80211_radar_event(). * To cancel the CAC, pass the channel context as well where radar is detected to ieee80211_dfs_cac_cancel(). This ensures that CAC is canceled only on the links using the provided context, leaving other links unaffected. This would also help in scenarios where there is split phy 5 GHz radio, which is capable of DFS channels in both lower and upper band. In this case, simultaneous radars can be detected. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-9-quic_adisi@quicinc.com Signed-off-by: Johannes Berg

wifi: mac80211: export ieee80211_purge_tx_queue() for drivers

2024-08-27T08:28:55+00:00

Drivers need to purge TX SKB when stopping. Using skb_queue_purge() can't report TX status to mac80211, causing ieee80211_free_ack_frame() warns "Have pending ack frames!". Export ieee80211_purge_tx_queue() for drivers to not have to reimplement it. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240822014255.10211-1-pkshih@realtek.com Signed-off-by: Johannes Berg

wifi: mac80211: Add non-atomic station iterator

2024-08-27T08:28:53+00:00

Drivers may at times want to iterate their stations with a function which requires some non-atomic operations. ieee80211_iterate_stations_mtx() introduces an API to iterate stations while holding that wiphy's mutex. This allows the iterating function to do non-atomic operations safely. Signed-off-by: Rory Little Link: https://patch.msgid.link/20240806004024.2014080-2-rory@candelatech.com [unify internal list iteration functions] Signed-off-by: Johannes Berg

wifi: mac80211: don't use rate mask for offchannel TX either

2024-08-27T08:13:23+00:00

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024 Reported-by: syzbot+8dd98a9e98ee28dc484a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-wireless/000000000000fdef8706191a3f7b@google.com/ Fixes: 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band") Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240729074816.20323-1-pkshih@realtek.com 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