kernel/linux.git/net/mac80211/debugfs_sta.c, branch v6.18.21

wifi: mac80211: Remove redundant rcu_read_lock/unlock() in spin_lock

2025-09-19T09:48:14+00:00

Since commit a8bb74acd8efe ("rcu: Consolidate RCU-sched update-side function definitions") there is no difference between rcu_read_lock(), rcu_read_lock_bh() and rcu_read_lock_sched() in terms of RCU read section and the relevant grace period. That means that spin_lock(), which implies rcu_read_lock_sched(), also implies rcu_read_lock(). There is no need no explicitly start a RCU read section if one has already been started implicitly by spin_lock(). Simplify the code and remove the inner rcu_read_lock() invocation. Cc: Johannes Berg Signed-off-by: pengdonglin Signed-off-by: pengdonglin Link: https://patch.msgid.link/20250916044735.2316171-11-dolinux.peng@gmail.com Signed-off-by: Johannes Berg

Revert "mac80211: Dynamically set CoDel parameters per station"

2025-04-23T13:22:11+00:00

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

net, treewide: define and use MAC_ADDR_STR_LEN

2025-03-19T18:17:58+00:00

There are a few places in the tree which compute the length of the string representation of a MAC address as 3 * ETH_ALEN - 1. Define a constant for this and use it where relevant. No functionality changes are expected. Signed-off-by: Uday Shankar Reviewed-by: Michal Swiatkowski Acked-by: Johannes Berg Reviewed-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312-netconsole-v6-1-3437933e79b8@purestorage.com Signed-off-by: Paolo Abeni

wifi: mac80211: convert debugfs files to short fops

2024-10-23T14:47:07+00:00

Given the large size of the regular struct file_operations, save a lot of space with the newly added short fops for debugfs. Link: https://patch.msgid.link/20241022151838.2f6de3ea3ecc.I45657e6a8415d796ec95c95becc9efb377ee3be6@changeid Signed-off-by: Johannes Berg

wifi: mac80211: fix spelling typo in comment

2024-01-03T14:34:56+00:00

Fix spelling of "attributes" in a comment. Reported-by: k2ci Signed-off-by: Zheng tan Link: https://msgid.link/20240102015418.3673858-1-tanzheng@kylinos.cn Signed-off-by: Johannes Berg

wifi: mac80211: use wiphy locked debugfs helpers for agg_status

2023-11-27T10:25:01+00:00

The read is currently with RCU and the write can deadlock, convert both for the sake of illustration. Make mac80211 depend on cfg80211 debugfs to get the helpers, but mac80211 debugfs without it does nothing anyway. This also required some adjustments in ath9k. Signed-off-by: Johannes Berg

wifi: mac80211: lock wiphy for aggregation debugfs

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

To change aggregation status may call into the driver, lock the wiphy for this. Signed-off-by: Johannes Berg

wifi: mac80211: add eht_capa debugfs field

2023-06-19T15:34:55+00:00

Output looks like this: [root@ct523c-0b29 ~]# cat /debug/ieee80211/wiphy6/netdev\:wlan6/stations/50\:28\:4a\:bd\:f4\:a7/eht_capa EHT supported MAC-CAP: 0x82 0x00 PHY-CAP: 0x0c 0x00 0x00 0x00 0x00 0x48 0x00 0x00 0x00 OM-CONTROL MAX-MPDU-LEN: 11454 242-TONE-RU-GT20MHZ NDP-4-EHT-LFT-32-GI BEAMFORMEE-80-NSS: 0 BEAMFORMEE-160-NSS: 0 BEAMFORMEE-320-NSS: 0 SOUNDING-DIM-80-NSS: 0 SOUNDING-DIM-160-NSS: 0 SOUNDING-DIM-320-NSS: 0 MAX_NC: 0 PPE_THRESHOLD_PRESENT NOMINAL_PKT_PAD: 0us MAX-NUM-SUPP-EHT-LTF: 1 SUPP-EXTRA-EHT-LTF MCS15-SUPP-MASK: 0 EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=2, Tx=2 EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=2, Tx=2 EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=2, Tx=2 EHT bw <= 160 MHz, max NSS for MCS 8-9: Rx=0, Tx=0 EHT bw <= 160 MHz, max NSS for MCS 10-11: Rx=0, Tx=0 EHT bw <= 160 MHz, max NSS for MCS 12-13: Rx=0, Tx=0 EHT bw <= 320 MHz, max NSS for MCS 8-9: Rx=0, Tx=0 EHT bw <= 320 MHz, max NSS for MCS 10-11: Rx=0, Tx=0 EHT bw <= 320 MHz, max NSS for MCS 12-13: Rx=0, Tx=0 EHT PPE Thresholds: 0xc1 0x0e 0xe0 0x00 0x00 Signed-off-by: Ben Greear Link: https://lore.kernel.org/r/20230517184428.999384-1-greearb@candelatech.com Signed-off-by: Johannes Berg

wifi: mac80211: Proper mark iTXQs for resumption

2023-01-10T12:24:12+00:00

When a running wake_tx_queue() call is aborted due to a hw queue stop the corresponding iTXQ is not always correctly marked for resumption: wake_tx_push_queue() can stops the queue run without setting @IEEE80211_TXQ_STOP_NETIF_TX. Without the @IEEE80211_TXQ_STOP_NETIF_TX flag __ieee80211_wake_txqs() will not schedule a new queue run and remaining frames in the queue get stuck till another frame is queued to it. Fix the issue for all drivers - also the ones with custom wake_tx_queue callbacks - by moving the logic into ieee80211_tx_dequeue() and drop the redundant @txqs_stopped. @IEEE80211_TXQ_STOP_NETIF_TX is also renamed to @IEEE80211_TXQ_DIRTY to better describe the flag. Fixes: c850e31f79f0 ("wifi: mac80211: add internal handler for wake_tx_queue") Signed-off-by: Alexander Wetzel Link: https://lore.kernel.org/r/20221230121850.218810-1-alexander@wetzel-home.de Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg

wifi: mac80211: Drop support for TX push path

2022-10-10T09:06:14+00:00

All drivers are now using mac80211 internal queues (iTXQs). Drop mac80211 internal support for the old push path. Signed-off-by: Alexander Wetzel Signed-off-by: Johannes Berg