summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2026-04-15 14:42:17 +0200
committerJohannes Berg <johannes.berg@intel.com>2026-04-28 09:29:02 +0200
commit2abfda2ad2edf49a97bb93c608908b9130318efc (patch)
tree397b5ed19b219261dae9d8104f07c5603a721e93 /include/linux
parent3967fe47e1d1bb886d2dc5c7267ada7c1653a3a4 (diff)
wifi: mac80211: clarify per-STA bandwidth handling
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 <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260415144514.09ae71b74d5c.Ib59c2ac82e030559d1f7d462f06ba3488a090946@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions