kernel.git/net/mac80211/main.c, branch linux-6.9.y

wifi: mac80211: disable softirqs for queued frame handling

2024-07-25T07:53:41Z

commit 321028bc45f01edb9e57b0ae5c11c5c3600d00ca upstream. As noticed by syzbot, calling ieee80211_handle_queued_frames() (and actually handling frames there) requires softirqs to be disabled, since we call into the RX code. Fix that in the case of cleaning up frames left over during shutdown. Fixes: 177c6ae9725d ("wifi: mac80211: handle tasklet frames before stopping") Reported-by: syzbot+1d516edf1e74469ba5d3@syzkaller.appspotmail.com Link: https://patch.msgid.link/20240626091559.cd6f08105a6e.I74778610a5ff2cf8680964698131099d2960352a@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

wifi: mac80211: handle tasklet frames before stopping

2024-07-25T07:53:21Z

[ Upstream commit 177c6ae9725d783f9e96f02593ce8fb2639be22f ] The code itself doesn't want to handle frames from the driver if it's already stopped, but if the tasklet was queued before and runs after the stop, then all bets are off. Flush queues before actually stopping, RX should be off at this point since all the interfaces are removed already, etc. Reported-by: syzbot+8830db5d3593b5546d2e@syzkaller.appspotmail.com Link: https://msgid.link/20240515135318.b05f11385c9a.I41c1b33a2e1814c3a7ef352cd7f2951b91785617@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: don't use sband->band early

2024-02-08T14:00:44Z

Some drivers may (notably mt76 does) not set up sband->band before registering, and cfg80211 will fill it in later. But since the HT/HE capability check mac80211 required it to be initialized already, otherwise failing things. This really isn't necessary though since the code is iterating the list of bands, and has the 'band' variable available. Fix it to not require the sband->band to be initialized already. Fixes: f04d2c247e04 ("wifi: mac80211: disallow drivers with HT wider than HE") Reported-by: Bert Karwatzki Debugged-by: Bert Karwatzki Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218466 Link: https://msgid.link/20240207115920.43cbedffb5c3.I4968e12275a3f95926e3f3ccae81e50f23fe4d4d@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: simplify non-chanctx drivers

2024-02-08T11:58:32Z

There are still surprisingly many non-chanctx drivers, but in mac80211 that code is a bit awkward. Simplify this by having those drivers assign 'emulated' ops, so that the mac80211 code can be more unified between non-chanctx/chanctx drivers. This cuts the number of places caring about it by about 15, which are scattered across - now they're fewer and no longer in the channel context handling. Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid Signed-off-by: Johannes Berg

wifi: mac80211: disallow drivers with HT wider than HE

2024-01-26T08:39:50Z

To simplify the code in the next patch, disallow drivers supporting 40 MHz in HT but not HE, since we'd otherwise have to track local maximum bandwidth per mode there. Signed-off-by: Johannes Berg Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240111181514.da15fe3214d2.I4df51ad2f4c844615c168bf9bdb498925b3c77d4@changeid Signed-off-by: Johannes Berg

wifi: mac80211: add support for SPP A-MSDUs

2024-01-26T08:39:49Z

If software crypto is used, simply add support for SPP A-MSDUs (and use it whenever enabled as required by the cfg80211 API). If hardware crypto is used, leave it up to the driver to set the NL80211_EXT_FEATURE_SPP_AMSDU_SUPPORT flag and then check sta->spp_amsdu or the IEEE80211_KEY_FLAG_SPP_AMSDU key flag. Signed-off-by: Johannes Berg Signed-off-by: Daniel Gabay Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240102213313.b8ada4514e2b.I1ac25d5f158165b5a88062a5a5e4c4fbeecf9a5d@changeid Signed-off-by: Johannes Berg

wifi: mac80211: process and save negotiated TID to Link mapping request

2024-01-26T08:39:48Z

An MLD may send TID-to-Link mapping request frame to negotiate TID to link mapping with a peer MLD. Support handling negotiated TID-to-Link mapping request frame by parsing the frame, asking the driver whether it supports the received mapping or not, and sending a TID-to-Link mapping response to the AP MLD. Theoretically, links that became inactive due to the received TID-to-Link mapping request, can be selected to be activated but this would require tearing down the negotiated TID-to-Link mapping, which is still not supported. Signed-off-by: Ayala Beker Reviewed-by: Johannes Berg Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240102213313.0bc1a24fcc9d.Ie72e47dc6f8c77d4a2f0947b775ef6367fe0edac@changeid Signed-off-by: Johannes Berg

wifi: mac80211: Add support for WBRF features

2023-12-12T09:36:59Z

To support the WBRF mechanism, Wifi adapters utilized in the system must register the frequencies in use (or unregister those frequencies no longer used) via the dedicated calls. So that, other drivers responding to the frequencies can take proper actions to mitigate possible interference. Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Co-developed-by: Evan Quan Signed-off-by: Evan Quan Signed-off-by: Ma Jun Link: https://msgid.link/20231211100630.2170152-5-Jun.Ma2@amd.com Signed-off-by: Johannes Berg

wifi: mac80211: rename ieee80211_tx_status() to ieee80211_tx_status_skb()

2023-10-23T10:26:51Z

make htmldocs warns: Documentation/driver-api/80211/mac80211:109: ./include/net/mac80211.h:5170: WARNING: Duplicate C declaration, also defined at mac80211:1117. Declaration is '.. c:function:: void ieee80211_tx_status (struct ieee80211_hw *hw, struct sk_buff *skb)'. This is because there's a function named ieee80211_tx_status() and a struct named ieee80211_tx_status. This has been discussed previously but no solution found: https://lore.kernel.org/all/20220521114629.6ee9fc06@coco.lan/ There's also a bug open for three years with no solution in sight: https://github.com/sphinx-doc/sphinx/pull/8313 So I guess we have no other solution than to a workaround this in the code, for example to rename the function to ieee80211_tx_status_skb() to avoid the name conflict. I got the idea for the name from ieee80211_tx_status_noskb() in which the skb is not provided as an argument, instead with ieee80211_tx_status_skb() the skb is provided. Compile tested only. Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231012114229.2931808-2-kvalo@kernel.org Signed-off-by: Johannes Berg