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

wifi: mac80211: clarify IEEE80211_STATUS_SUBDATA_MASK

2024-03-25T14:39:28Z

We have 13 bits for the status_data, so restricting type to 4 and subdata to 8 bits is confusing, even if we don't need more bits now. Change subdata mask to be 9 bits instead, just to make things match up. If we actually need more types or more subdata bits we can later also reshuffle the bits between these, but we should probably keep them at 13 bits together. Signed-off-by: Johannes Berg Reviewed-by: Ayala Beker Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320091155.28ac7b665039.I1abbb13e90f016cab552492e05f5cb5b52de6463@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: trace SMPS requests from driver

2024-02-02T13:20:42Z

Even if there are a lot of possible ways drivers might call this, at least knowing when they do and with what settings can be useful. Add tracing for it. Link: https://msgid.link/20240129195435.b20d2ead2013.I8213e65c274451d523a3397519ac578c3ed2df4d@changeid [removed link-id contortions as suggested by Jeff] Signed-off-by: Johannes Berg

wifi: mac80211: handle 320 MHz in ieee80211_ht_cap_ie_to_sta_ht_cap

2023-11-24T17:42:18Z

The new 320 MHz channel width wasn't handled, so connecting a station to a 320 MHz AP would limit the station to 20 MHz (on HT) after a warning, handle 320 MHz to fix that. Signed-off-by: Ben Greear Link: https://lore.kernel.org/r/20231109182201.495381-1-greearb@candelatech.com [write a proper commit message] Signed-off-by: Johannes Berg

wifi: mac80211: remove ampdu_mlme.mtx

2023-09-11T09:27:22Z

We now hold the wiphy mutex everywhere that we use or needed the A-MPDU locking, so we don't need this mutex any more. Remove it. Most of this change was done automatically with spatch. Signed-off-by: Johannes Berg

wifi: mac80211: convert A-MPDU work to wiphy work

2023-09-11T09:27:19Z

Convert the A-MPDU work to wiphy work so it holds the wiphy mutex and we can later guarantee that to drivers. It might seem that we could run these concurrently for different stations, but they're all on the ordered mac80211 workqueue, so this shouldn't matter for that. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg

wifi: mac80211: fix SMPS status handling

2023-09-11T09:27:18Z

The current SMPS status handling isn't per link, so we only ever change the deflink, which is obviously wrong, it's not even used for multi-link connections, but the request API actually includes the link ID. Use the new status_data changes to move the handling to the right link, this also saves parsing the frame again on the status report, instead we can now check only if it was an SMPS frame. Of course, move the worker to be a wiphy work so that we're able to cancel it safely for the link. Signed-off-by: Johannes Berg

wifi: mac80211: Fix SMPS handling in the context of MLO

2023-09-11T09:27:18Z

When the connection is a MLO connection, a SMPS request should be sent on a specific link, as SMPS is BSS specific, and the DA and BSSID used for the action frame transmission should be the AP MLD address, as the underlying driver is expected to perform the address translation (based on the link ID). Fix the SMPS request handling to use the AP MLD address and provide the link ID for the request processing during Tx. Signed-off-by: Ilan Peer Signed-off-by: Johannes Berg

wifi: mac80211: use wiphy work for SMPS

2023-06-07T17:53:22Z

SMPS requests are per link, and currently there's a potential deadlock with canceling. Use the new wiphy work to handle SMPS instead, so that the cancel cannot deadlock. Signed-off-by: Johannes Berg

wifi: mac80211: Fix iTXQ AMPDU fragmentation handling

2023-01-10T12:24:17Z

mac80211 must not enable aggregation wile transmitting a fragmented MPDU. Enforce that for mac80211 internal TX queues (iTXQs). Reported-by: kernel test robot Link: https://lore.kernel.org/oe-lkp/202301021738.7cd3e6ae-oliver.sang@intel.com Signed-off-by: Alexander Wetzel Link: https://lore.kernel.org/r/20230106223141.98696-1-alexander@wetzel-home.de Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg