kernel/git/stable/linux.git/net/mac80211/he.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: 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

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: simplify ieee80211_recalc_chanctx_min_def() API

2025-11-10T09:38:50+00:00

ieee80211_recalc_chanctx_min_def() is used outside the chandef code, but then should/is always used with NULL/false for the two last arguments. Remove them, and create another level of indirection for use inside the file. Link: https://patch.msgid.link/20251105160431.33408844c392.I4f52298861780c17a27cd229609e8a3e29c8d740@changeid Signed-off-by: Johannes Berg

wifi: mac80211: add some support for RX OMI power saving

2025-01-13T14:26:43+00:00

In order to save power, it can be desirable to change the RX operating mode using OMI to reduce the bandwidth. As the handshake must be done in the HTC+ field, it cannot be done by mac80211 directly, so expose functions to the driver to request and finalize the necessary updates. Note that RX OMI really only changes what the peer (AP) will transmit to us, but in order to use it to actually save some power (by reducing the listen bandwidth) we also update rate scaling and then the channel context's mindef accordingly. The updates are split into two in order to sequence them correctly, when reducing bandwidth first reduce the rate scaling and thus TX, then send OMI, then reduce the listen bandwidth (chandef); when increasing bandwidth this is the other way around. This also requires tracking in different variables which part is applicable already. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250101070249.2c1a1934bd73.I4e90fd503504e37f9eac5bdae62e3f07e7071275@changeid Signed-off-by: Johannes Berg