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

wifi: mac80211: refactor link STA bandwidth update

2026-06-03T12:11:58+00:00

There's similar code in two places in HT and HE, and we need to add the same again for UHR. Rename ieee80211_link_sta_rc_update_omi() to ieee80211_link_sta_update_rc_bw() and move it to sta_info.c and update existing code that can use it to do so. Link: https://patch.msgid.link/20260529102644.577c2f304d33.I09df4fce83c4e3e6deddfecbea74ffdbeedb4927@changeid Signed-off-by: Johannes Berg

wifi: mac80211: clarify per-STA bandwidth handling

2026-04-28T07:29:02+00:00

The per-STA bandwidth handling is completely confusing, given the function names etc. Move everything to sta_info.c and rename the functions to accurately reflect what they return: - ieee80211_sta_bw_capability() - ieee80211_sta_current_bw() can return the appropriate bandwidth in the desired direction (a new enum) At any given time, the bandwidth with which we expect to receive frames from a station may differ from the bandwidth with which we may transmit frames to the station; this will happen either during RX OMI negotiation, or for a long time if the station used an HT Notify Channel Width frame. We also implement the (VHT) Operating Mode Notification as an asymmetric setting, even if the spec would seem to imply it could be symmetric. Also rename the 'cur_max_bandwidth' value to 'op_mode_bw' which matches the 'op_mode_nss', indicating more clearly what it _is_ rather than how it's _used_. It's not quite precise (NSS is) since it's also HT chanwidth notification, but that seems OK. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.09ae71b74d5c.Ib59c2ac82e030559d1f7d462f06ba3488a090946@changeid Signed-off-by: Johannes Berg

wifi: mac80211: remove ieee80211_sta_cur_vht_bw()

2026-04-28T07:27:47+00:00

We can now easily always call _ieee80211_sta_cur_vht_bw() with a valid chandef, so do that, remove ieee80211_sta_cur_vht_bw() and drop the underscore prefix. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.73659adc198f.Ic8fc88a7e016e62d00dca380ffbf47a54ef3daef@changeid Signed-off-by: Johannes Berg

wifi: mac80211: clean up initial STA NSS/bandwidth handling

2026-04-28T07:27:46+00:00

Currently, the initial STA bandwidth is set during each parsing of HT/VHT/... elements to the station capabilities, multiple times, in a confusing way that's not very good in the case of NAN stations either. For now, keep the NULL chandef pointer and all that, but clean up the initial handling of NSS/BW capabilities and then apply the VHT operation mode on top of that. This clarifies the code and the client code now also handles the bandwidth change from Operating Mode Notification in association response. The HT code is completely unnecessary now, since the VHT (soon to be renamed) function will be called and handles HT as well. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.a4d88eb27a8d.Id7a316e75e7e3dce2023d987e6939060f5286378@changeid Signed-off-by: Johannes Berg

wifi: mac80211: simplify ieee80211_sta_rx_bw_to_chan_width()

2026-04-28T07:27:46+00:00

This function is only called for at least HT capable stations, so doesn't need to differentiate 20/20_NOHT. Also, the check for VHT 160 MHz support is wrong, since a station could have support for both and the AP is using 80+80, but nothing cares anyway, so we don't need that. Simplify the function and move it to util.c since it now no longer is related to VHT, and also doesn't need a station. Also use the new function in ieee80211_get_sta_bw() for the chandef calculations, it just needs to handle the 20/20-noht separately; while at it fix that to handle HE stations. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.7b0be1059436.I573add4e3ed68b15f8b45122d053ac523afe4025@changeid Signed-off-by: Johannes Berg

wifi: mac80211: use max BW for HT channel width update

2026-04-28T07:27:45+00:00

When an HT channel width update comes in, don't use the capability of the station, but rather set it to max as the capability will be taken into account anyway when using the value. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.bab6e4195d78.I9683605229ed1b75ff5a9c14e967762e88b3fc36@changeid Signed-off-by: Johannes Berg

wifi: mac80211: set cur_max_bandwidth to maximum

2026-04-28T07:27:44+00:00

Instead of calculating the individual maximum for each station from its capabilities, just unconditionally set cur_max_bandwidth to IEEE80211_STA_RX_BW_MAX. This still works because cur_max_bandwidth is only used together with the capabilities of the station anyway, and then adjusted by HT channel width notification or VHT opmode notification action frames. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.43cdb11b5c7e.I99a7ea2ab10b6fffb68a401a26b98d546e428c11@changeid Signed-off-by: Johannes Berg

wifi: mac80211: support NAN stations

2026-04-07T13:36:03+00:00

Add support for both NMI and NDI stations. The NDI station will be linked to the NMI station of the NAN peer for which the NDI station is added. A peer can choose to reuse its NMI address as the NDI address. Since different keys might be in use for NAN management and for data frames, we will have 2 different stations, even if they'll have the same address. Even though there are no links in NAN, sta->deflink will still be used to store the one set of capabilities and SMPS mode. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260326121156.9fdd37b8e755.I7a7bd6e8e751cab49c329419485839afd209cfc6@changeid Signed-off-by: Johannes Berg

wifi: mac80211: don't consider the sband when processing capabilities

2026-03-24T15:32:16+00:00

In NAN, we have one set of (HT, VHT, HE) capabilities for all bands, which means that we will need to process those capabilities without a given sband. To prepare for that, remove the sband argument from ieee80211_ht_cap_ie_to_sta_ht_cap and ieee80211_he_cap_ie_to_sta_he_cap and pass our own capabilities instead. For ieee80211_vht_cap_ie_to_sta_vht_cap, make the sband argument optional, since it is also used to check if there is at least one channel that supports 80 MHz. (Note that this check doesn't make much sense, but this can be handled in a different patch.) Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260320141504.e42ef1f0eabb.If994d6346f00219437e22043e7bf2395b827b34a@changeid Signed-off-by: Johannes Berg

wifi: mac80211: add support for NDP ADDBA/DELBA for S1G

2026-03-06T09:52:11+00:00

S1G defines use of NDP Block Ack (BA) for aggregation, requiring negotiation of NDP ADDBA/DELBA action frames. If the S1G recipient supports HT-immediate block ack, the sender must send an NDP ADDBA Request indicating it expects only NDP BlockAck frames for the agreement. Introduce support for NDP ADDBA and DELBA exchange in mac80211. The implementation negotiates the BA mechanism during setup based on station capabilities and driver support (IEEE80211_HW_SUPPORTS_NDP_BLOCKACK). If negotiation fails due to mismatched expectations, a rejection with status code WLAN_STATUS_REJECTED_NDP_BLOCK_ACK_SUGGESTED is returned as per IEEE 802.11-2024. Trace sample: IEEE 802.11 Wireless Management Fixed parameters Category code: Block Ack (3) Action code: NDP ADDBA Request (0x80) Dialog token: 0x01 Block Ack Parameters: 0x1003, A-MSDUs, Block Ack Policy .... .... .... ...1 = A-MSDUs: Permitted in QoS Data MPDUs .... .... .... ..1. = Block Ack Policy: Immediate Block Ack .... .... ..00 00.. = Traffic Identifier: 0x0 0001 0000 00.. .... = Number of Buffers (1 Buffer = 2304 Bytes): 64 Block Ack Timeout: 0x0000 Block Ack Starting Sequence Control (SSC): 0x0010 .... .... .... 0000 = Fragment: 0 0000 0000 0001 .... = Starting Sequence Number: 1 IEEE 802.11 Wireless Management Fixed parameters Category code: Block Ack (3) Action code: NDP ADDBA Response (0x81) Dialog token: 0x02 Status code: BlockAck negotiation refused because, due to buffer constraints and other unspecified reasons, the recipient prefers to generate only NDP BlockAck frames (0x006d) Block Ack Parameters: 0x1002, Block Ack Policy .... .... .... ...0 = A-MSDUs: Not Permitted .... .... .... ..1. = Block Ack Policy: Immediate Block Ack .... .... ..00 00.. = Traffic Identifier: 0x0 0001 0000 00.. .... = Number of Buffers (1 Buffer = 2304 Bytes): 64 Block Ack Timeout: 0x0000 Signed-off-by: Ria Thomas Link: https://patch.msgid.link/20260305091304.310990-1-ria.thomas@morsemicro.com Signed-off-by: Johannes Berg