kernel/git/next/linux-next.git/net/mac80211/vht.c, branch master

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 ieee80211_sta_cap_rx_bw()

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

There are three versions of this function, but now there's no caller to ieee80211_sta_cap_rx_bw() and the chandef is always given. Rename the functions to have one underscore less and rely on the chandef being passed. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.62f48003f11c.Ib84ab7aeab8b278ab46d85b142a66bf330909eb6@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: clean up STA NSS handling

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

Move ieee80211_sta_init_nss() from VHT code to station code, and disentangle it from rate control. This way, it becomes clearer when 'rx_nss' is set up. While doing this, fix the client side code to set up link_sta->op_mode_nss instead of link_sta->pub->rx_nss for the opmode element in association response, and remove the (now wrong) comment about handling that in the function. type=cleanup ticket=none Signed-off-by: Johannes Berg Reviewed-on: https://gerritwcs.ir.intel.com/c/iwlwifi-stack-dev/+/273695 Tested-by: iil_jenkins iil_jenkins tested: iil_jenkins iil_jenkins Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.bef3d07beeb6.I97fb93ccc1b366110ab23de58fcd73676cdd85d6@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: remove ieee80211_sta_cap_chan_bw()

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

This function is only used by TDLS, but is more or less equivalent to ieee80211_sta_cap_rx_bw() (which takes OMI into account, but that won't be used in TDLS), except it tries to differentiate 80+80 and 160, but then caller doesn't care about that. Remove the function. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.138728393e2b.I4ea9221cafcfd034dda430e76de82eec59ab1e71@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: remove NAN guards on ieee80211_sta_cur_vht_bw() calls

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

The NAN guards here make little sense, just don't WARN inside the function (and return maximum instead of minimum). Otherwise we need to guard more calls, such as in EHT in the future. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.be6bc3fd5fdf.I38ce6c763c361a3ce50618e820a0818eb18e49dd@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