kernel.git/net/mac80211/vht.c, branch master

wifi: mac80211: make VHT opmode NSS ignore a debug message

2025-07-15T08:59:11Z

There's no need to always print it, it's only useful for debugging specific client issues. Make it a debug message. Reported-by: Paul Menzel Link: https://lore.kernel.org/linux-wireless/20250529070922.3467-1-pmenzel@molgen.mpg.de/ Link: https://patch.msgid.link/20250708105849.22448-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg

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

2025-01-13T14:26:43Z

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

wifi: mac80211: expose ieee80211_chan_width_to_rx_bw() to drivers

2024-10-23T14:43:38Z

Drivers might need to also do this calculation, no point in them duplicating the code. Since it's so simple, just make it an inline. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241007144851.af003cb4a088.I8b5d29504b726caae24af6013c65b3daebe842a2@changeid Signed-off-by: Johannes Berg

wifi: mac80211: call rate_control_rate_update() for link STA

2024-10-23T14:43:27Z

In order to update the right link information, call the update rate_control_rate_update() with the right link_sta, and then pass that through to the driver's sta_rc_update() method. The software rate control still doesn't support it, but that'll be skipped by not having a rate control ref. Since it now operates on a link sta, rename the driver method. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241007144851.5851b6b5fd41.Ibdf50d96afa4b761dd9b9dfd54a1147e77a75329@changeid Signed-off-by: Johannes Berg

wifi: mac80211, cfg80211: miscellaneous spelling fixes

2024-10-08T19:52:09Z

Correct spelling here and there as suggested by codespell. Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20240913084919.118862-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg

wifi: mac80211: optionally pass chandef to ieee80211_sta_cur_vht_bw()

2024-06-26T08:21:54Z

We'll need this as well for channel switching cases, so add the ability now to pass the chandef to calculate for. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20240612143418.f70e05d9f306.Ifa0ce267de4f0ef3c21d063fb0cbf50e84d7d6ff@changeid Signed-off-by: Johannes Berg

wifi: mac80211: optionally pass chandef to ieee80211_sta_cap_rx_bw()

2024-06-26T08:21:52Z

We'll need this function to take a new chandef in (some) channel switching cases, so prepare for that by allowing that to be passed and using it if so. Clean up the code a little bit while at it. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20240612143418.772313f08b6a.If9708249e5870671e745d4c2b02e03b25092bea3@changeid Signed-off-by: Johannes Berg

wifi: mac80211: track capability/opmode NSS separately

2024-03-04T13:25:27Z

We're currently tracking rx_nss for each station, and that is meant to be initialized to the capability NSS and later reduced by the operating mode notification NSS. However, we're mixing up capabilities and operating mode NSS in the same variable. This forces us to recalculate the NSS capability on operating mode notification RX, which is a bit strange; due to the previous fix I had to never keep rx_nss as zero, it also means that the capa is never taken into account properly. Fix all this by storing the capability value, that can be recalculated unconditionally whenever needed, and storing the operating mode notification NSS separately, taking it into account when assigning the final rx_nss value. Cc: stable@vger.kernel.org Fixes: dd6c064cfc3f ("wifi: mac80211: set station RX-NSS on reconfig") Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240228120157.0e1c41924d1d.I0acaa234e0267227b7e3ef81a59117c8792116bc@changeid Signed-off-by: Johannes Berg

wifi: mac80211: introduce 'channel request'

2024-02-08T12:07:34Z

For channel contexts, mac80211 currently uses the cfg80211 chandef struct (control channel, center freq(s), width) to define towards drivers and internally how these behave. In fact, there are _two_ such structs used, where the min_def can reduce bandwidth according to the stations connected. Unfortunately, with EHT this is longer be sufficient, at least not for all hardware. EHT requires that non-AP STAs that are connected to an AP with a lower bandwidth than it (the AP) advertises (e.g. 160 MHz STA connected to 320 MHz AP) still be able to receive downlink OFDMA and respond to trigger frames for uplink OFDMA that specify the position and bandwidth for the non-AP STA relative to the channel the AP is using. Therefore, they need to be aware of this, and at least for some hardware (e.g. Intel) this awareness is in the hardware. As a result, use of the "same" channel may need to be split over two channel contexts where they differ by the AP being used. As a first step, introduce a concept of a channel request ('chanreq') for each interface, to control the context it requests. This step does nothing but reorganise the code, so that later the AP's chandef can be added to the request in order to handle the EHT case described above. Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid Signed-off-by: Johannes Berg

wifi: mac80211: work around Cisco AP 9115 VHT MPDU length

2023-09-25T06:41:27Z

Cisco AP module 9115 with FW 17.3 has a bug and sends a too large maximum MPDU length in the association response (indicating 12k) that it cannot actually process. Work around that by taking the minimum between what's in the association response and the BSS elements (from beacon or probe response). Signed-off-by: Johannes Berg Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20230918140607.d1966a9a532e.I090225babb7cd4d1081ee9acd40e7de7e41c15ae@changeid Signed-off-by: Johannes Berg