summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)AuthorFilesLines
2024-05-03wifi: mac80211: handle color change per linkAditya Kumar Singh2-49/+102
In order to support color change with MLO, handle the link ID now passed from cfg80211, adjust the code to do everything per link and call the notifications to cfg80211 correctly. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240422053412.2024075-4-quic_adisi@quicinc.com Link: https://msgid.link/20240422053412.2024075-5-quic_adisi@quicinc.com Link: https://msgid.link/20240422053412.2024075-6-quic_adisi@quicinc.com Link: https://msgid.link/20240422053412.2024075-7-quic_adisi@quicinc.com [squash, move API call updates to this patch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-03wifi: cfg80211: handle color change per linkAditya Kumar Singh1-5/+5
Currently, during color change, no link id information is passed down. In order to support color change during Multi Link Operation, it is required to pass link id as well. Additionally, update notification APIs to allow drivers/mac80211 to pass the link ID. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240422053412.2024075-2-quic_adisi@quicinc.com Link: https://msgid.link/20240422053412.2024075-3-quic_adisi@quicinc.com [squash, actually only pass 0 from mac80211] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski9-36/+134
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/ethernet/ti/icssg/icssg_prueth.c net/mac80211/chan.c 89884459a0b9 ("wifi: mac80211: fix idle calculation with multi-link") 87f5500285fb ("wifi: mac80211: simplify ieee80211_assign_link_chanctx()") https://lore.kernel.org/all/20240422105623.7b1fbda2@canb.auug.org.au/ net/unix/garbage.c 1971d13ffa84 ("af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc().") 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") drivers/net/ethernet/ti/icssg/icssg_prueth.c drivers/net/ethernet/ti/icssg/icssg_common.c 4dcd0e83ea1d ("net: ti: icssg-prueth: Fix signedness bug in prueth_init_rx_chns()") e2dc7bfd677f ("net: ti: icssg-prueth: Move common functions into a separate file") No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-19wifi: mac80211: handle link ID during management TxSriram R1-1/+11
During non-STA management Tx, when source address is same as one of the link addresses and even when userspace requested Tx on a specific link, the link ID is not set in the TX control information. Now if the MLD address is also the same as that of the link address, then mac80211 fills link as "unspecified", since it looks like MLD TX. This is unexpected, however, since non-STA TX must specify which link to use. In hwsim, this will (after warnings) result in dropping such frames as well. Use and set the link id if the link bss is matching the address and requested channel. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240410052705.169865-1-quic_adisi@quicinc.com Link: https://lore.kernel.org/r/0496fb7e-53cc-476f-8052-985d82fd8d01@quicinc.com [reword commit message, should spell out hwsim etc.] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: handle sdata->u.ap.active flag with MLOAditya Kumar Singh1-3/+7
Currently whenever link AP beacon is assigned, sdata->u.ap.active flag is set and whenever it is brought down, the flag is reset. However, with MLO, all the links of the same MLD would use the same sdata. Hence there is no need to set/reset for each link up/down. Also, resetting it when only one of the links went down is not desirable. Add changes to set the active flag only when first link is assigned beacon. Similarly, add changes to reset that flag only when last link is brought down. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240409094017.3165560-1-quic_adisi@quicinc.com [remove unnecessary check before constant true assignment] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: add return docs for sta_info_flush()Johannes Berg1-2/+2
Use the Return: annotation instead of spelling out "Returns" in the documentation, for both sta_info_flush()/__sta_info_flush(). Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: keep mac80211 consistent on link activation failureBenjamin Berg3-16/+52
In the unlikely event that link_use_channel fails while activating a link, mac80211 would go into a bad state. Unfortunately, we cannot completely avoid failures from drivers in this case. However, what we can do is to just continue internally anyway and assume the driver is going to trigger a recovery flow from its side. Doing that means that we at least have a consistent state in mac80211 allowing such a recovery flow to succeed. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://msgid.link/20240418115219.1129e89f4b55.I6299678353e50e88b55c99b0bce15c64b52c2804@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: simplify ieee80211_assign_link_chanctx()Johannes Berg1-8/+9
There's no need for a label/goto here, the only thing is that drv_assign_vif_chanctx() must succeed to set 'conf' and add the new context to the list, the remaining code is (and must be) the same regardless. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://msgid.link/20240418115219.a94852030d33.I9d647178ab25636372ed79e5312c68a06e0bf60c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: reserve chanctx during findJohannes Berg1-2/+29
When searching for a chanctx for re-use, it's later adjusted and assigned. It may also be that another one is already assigned to the link in question, so unassign can also happen. In short, the driver is called multiple times. During these callbacks, it may thus change active links (on another interface), which then can in turn cause the found chanctx (that's going to be reused) to get removed and freed. To avoid this, temporarily assign it to the reserved chanctx and track the link that wants to use it in the reserved_links list. This causes the ieee80211_chanctx_refcount() to be increased by one during these operations, thus avoiding the free. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://msgid.link/20240418115219.94ea84c8ee1e.I0b247dbc0cd937ae6367bc0fc7e8d156b5d5f9b1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: defer link switch work in reconfigMiri Korenblit2-0/+12
If a link switch work was queued, and then a restart happened, the worker might be executed before the reconfig, and obviously it will fail (the HW might not respond to updates etc.) So, don't perform the switch if we are in reconfig, instead - do it at the end of the reconfig. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240415112355.1ef1008e3a0a.I19add3f2152dcfd55a759de97b1d09265c1cde98@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: transmit deauth only if link is availableJohannes Berg4-26/+46
There's an issue in that when we disconnect from an AP due to the AP switching to an unsupported channel, we might not tell the driver about this before we try to send the deauth. If the underlying implementation has detected the quiet CSA, this may cause issues if this is the only active link. Avoid this by transmitting (and flushing) the deauth only when there's an active link available that's not affected by quiet CSA. Since this introduces link->u.mgd.csa_blocked_tx and we no longer check sdata->csa_blocked_tx for the TX itself also rename the latter to csa_blocked_queues. Fixes: 6f0107d195a8 ("wifi: mac80211: introduce a feature flag for quiet in CSA") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240415112355.1d91db5e95aa.Iad3a5df3367f305dff48cd61776abfd6cf0fd4ab@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: fix unaligned le16 accessJohannes Berg1-1/+1
The AP removal timer field need not be aligned, so the code shouldn't access it directly, but use unaligned loads. Use get_unaligned_le16(), which even is shorter than the current code since it doesn't need a cast. Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element") Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240418105220.356788ba0045.I2b3cdb3644e205d5bb10322c345c0499171cf5d2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: remove link before APJohannes Berg1-2/+5
If the AP removal timer is long, we don't really want to remove the link immediately. However, we really should do it _before_ the AP removes it (which happens at or after count reaches 0), so subtract 1 from the countdown when scheduling the timer. This causes the link removal work to run just after the beacon with value 1 is received. If the counter is already zero, do it immediately. This fixes an issue where we do the removal too late and receive a beacon from the AP that's no longer associated with the MLD, but thus removed EHT and ML elements, and then we disconnect instead from the whole MLD, since one of the associated APs changed mode from EHT to HE. Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element") Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240418105220.03ac4a09fa74.Ifb8c8d38e3402721a81ce5981568f47b5c5889cb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: mlme: re-parse if AP mode is less than clientJohannes Berg1-4/+9
If the AP mode ends up being determined less than the client mode, there may be different reasons for this, e.g. AP misconfiguration. If this happens in a way that causes e.g. EHT to be rejected, the elements need to be re-parsed since we'll connect as HE, but not reparsing means that we'll still think it's OK to use multi-link, so we can connect in a non-sensical configuration of advertising only HE on a secondary link. This normally won't happen for the assoc link because that reuses the mode from authentication, and if that's not EHT, multi-link association is rejected. Fix this inconsistency by parsing the elements again if the mode was different from the first parsing attempt. Print the message a bit later to avoid printing "determined AP ... to be HE" twice in cases where ieee80211_determine_ap_chan() returned a lesser mode, rather than the regulatory downgrades below changing it. Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240418105220.d1f25d92cfe7.Ia21eff6cdcae2f5aca13cf8e742a986af5e70f89@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: mlme: fix memory leakJohannes Berg1-1/+3
When re-parsing the elements here (with changed mode), free the original ones first to avoid leaking memory. Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240418105220.458421e3bbff.Icb5b84cba3ea420794cf009cf18ec3d76e434736@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: mlme: re-parse with correct modeJohannes Berg1-1/+1
When doing re-parsing in ieee80211_determine_chan_mode(), the conn->mode is changed, and the whole point of doing the parsing again was to parse as the downgraded mode. However, that didn't actually work, because the setting was copied before and never changed again. Fix that. Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240418105220.5e0d1fcb5622.Ib0673e0bc90033fd6d387b6a5f107c040eb907cf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-19wifi: mac80211: fix idle calculation with multi-linkJohannes Berg1-5/+22
The vif's idle state doesn't automatically go to true when any link removes the channel context, it's only idle when _all_ links no longer have a channel context. Fix that. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240418105220.90df97557702.I05d2228ce85c203b9f2d6da8538cc16dce46752a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-17wifi: mac80211: split mesh fast tx cache into local/proxied/forwardedFelix Fietkau4-16/+72
Depending on the origin of the packets (and their SA), 802.11 + mesh headers could be filled in differently. In order to properly deal with that, add a new field to the lookup key, indicating the type (local, proxied or forwarded). This can fix spurious packet drop issues that depend on the order in which nodes/hosts communicate with each other. Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://msgid.link/20240415121811.13391-1-nbd@nbd.name [use sizeof_field() for key_len] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: extend IEEE80211_KEY_FLAG_GENERATE_MMIE to other ciphersMichael-CY Lee1-2/+10
Extend the flag IEEE80211_KEY_FLAG_GENERATE_MMIE to BIP-CMAC-256, BIP-GMAC-128 and BIP-GMAC-256 for the same reason and in the same way that the flag was added originally in commit a0b4496a4368 ("mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flags"). Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://msgid.link/20240326003036.15215-1-michael-cy.lee@mediatek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: correctly document struct mesh_tableJeff Johnson1-1/+1
Currently kernel-doc -Wall reports: net/mac80211/ieee80211_i.h:687: warning: missing initial short description on line: * struct mesh_table So add a short description. Reported-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/linux-wireless/a009a21a-56d7-4a1a-aaf9-feefa5acc561@infradead.org/ Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://msgid.link/20240328-mesh_table-kerneldoc-v1-1-174c4df341b1@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: ensure beacon is non-S1G prior to extracting the beacon ↵Richard Kinder1-1/+2
timestamp field Logic inside ieee80211_rx_mgmt_beacon accesses the mgmt->u.beacon.timestamp field without first checking whether the beacon received is non-S1G format. Fix the problem by checking the beacon is non-S1G format to avoid access of the mgmt->u.beacon.timestamp field. Signed-off-by: Richard Kinder <richard.kinder@gmail.com> Link: https://msgid.link/20240328005725.85355-1-richard.kinder@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: don't use rate mask for scanningJohannes Berg3-5/+15
The rate mask is intended for use during operation, and can be set to only have masks for the currently active band. As such, it cannot be used for scanning which can be on other bands as well. Simply ignore the rate masks during scanning to avoid warnings from incorrect settings. Reported-by: syzbot+fdc5123366fb9c3fdc6d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fdc5123366fb9c3fdc6d Co-developed-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Tested-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://msgid.link/20240326220854.9594cbb418ca.I7f86c0ba1f98cf7e27c2bacf6c2d417200ecea5c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: check EHT/TTLM action frame lengthJohannes Berg1-0/+4
Check the EHT action frame length before accessing the action code, if it's not present then the frame cannot be valid. Reported-by: syzbot+75af45a00cf13243ba39@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/0000000000006c06870614886611@google.com/ Fixes: 8f500fbc6c65 ("wifi: mac80211: process and save negotiated TID to Link mapping request") Link: https://msgid.link/20240326213858.19c84f34349f.I71b439f016b28f65284bb7646fe36343b74cbc9a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-03Merge tag 'wireless-next-2024-04-03' of ↵Jakub Kicinski13-56/+161
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.10 The first "new features" pull request for v6.10 with changes both in stack and in drivers. The big thing in this pull request is that wireless subsystem is now almost free of sparse warnings. There's only one warning left in ath11k which was introduced in v6.9-rc1 and will be fixed via the wireless tree. Realtek drivers continue to improve, now we have support for RTL8922AE and RTL8723CS devices. ath11k also has long waited support for P2P. This time we have a small conflict in iwlwifi, Stephen has an example merge resolution which should help with fixing the conflict: https://lore.kernel.org/all/20240326100945.765b8caf@canb.auug.org.au/ Major changes: rtw89 * RTL8922AE Wi-Fi 7 PCI device support rtw88 * RTL8723CS SDIO device support iwlwifi * don't support puncturing in 5 GHz * support monitor mode on passive channels * BZ-W device support * P2P with HE/EHT support ath11k * P2P support for QCA6390, WCN6855 and QCA2066 * tag 'wireless-next-2024-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (122 commits) wifi: mt76: mt7915: workaround dubious x | !y warning wifi: mwl8k: Avoid -Wflex-array-member-not-at-end warnings wifi: ti: Avoid a hundred -Wflex-array-member-not-at-end warnings wifi: iwlwifi: mvm: fix check in iwl_mvm_sta_fw_id_mask net: rfkill: gpio: Convert to platform remove callback returning void wifi: mac80211: use kvcalloc() for codel vars wifi: iwlwifi: reconfigure TLC during HW restart wifi: iwlwifi: mvm: don't change BA sessions during restart wifi: iwlwifi: mvm: select STA mask only for active links wifi: iwlwifi: mvm: set wider BW OFDMA ignore correctly wifi: iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD cmd v9 wifi: iwlwifi: mvm: Declare HE/EHT capabilities support for P2P interfaces wifi: iwlwifi: mvm: Remove outdated comment wifi: iwlwifi: add support for BZ_W wifi: iwlwifi: Print a specific device name. wifi: iwlwifi: remove wrong CRF_IDs wifi: iwlwifi: remove devices that never came out wifi: iwlwifi: mvm: mark EMLSR disabled in cleanup iterator wifi: iwlwifi: mvm: fix active link counting during recovery wifi: iwlwifi: mvm: assign link STA ID lookups during restart ... ==================== Link: https://lore.kernel.org/r/20240403093625.CF515C433C7@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-25wifi: mac80211: use kvcalloc() for codel varsJohannes Berg1-3/+3
This is a big array, but it's only used by software and need not be contiguous in memory. Use kvcalloc() since it's so big (order 5 allocation). Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240325150509.9195643699e4.I1b94b17abc809491080d6312f31ce6b5decdd446@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: reactivate multi-link later in restartJohannes Berg2-3/+11
In case of restart, we currently reactivate multi-link on interfaces before reconfiguring keys etc. which means the drivers need to handle this case differently. Enable more links later to allow them to handle it the same way. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320091155.d0f18a56335d.Ib3338d93872a4a568f38db0d02546534d3eff810@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: improve drop for action frame returnJohannes Berg2-3/+4
If we use a drop we not only save the extra call to dev_kfree_skb(), but also have a better reason in tracing, so do that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320091155.34daf0a89eb4.I60e0639511f9de64e40e6105b640adf90f8f57f7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: don't ask driver about no-op link changesJohannes Berg1-1/+4
If the links won't actually change, nothing will happen. This was previously done in the inner function (twice in some cases), but we shouldn't bother the driver with it. Clean that up. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320091155.a8190a312a27.If4e6f5ce8228eda7afac0fc8c17dd731c5da9ed9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: don't select link ID if not provided in scan requestAyala Beker1-12/+4
If scan request doesn't include a link ID to be used for TSF reporting, don't select it as it might become inactive before scan is actually started by the driver. Instead, let the driver select one of the active links. Fixes: cbde0b49f276 ("wifi: mac80211: Extend support for scanning while MLO connected") Signed-off-by: Ayala Beker <ayala.beker@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320091155.a6b643a15755.Ic28ed9a611432387b7f85e9ca9a97a4ce34a6e0f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: clarify IEEE80211_STATUS_SUBDATA_MASKJohannes Berg2-2/+2
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 <johannes.berg@intel.com> Reviewed-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320091155.28ac7b665039.I1abbb13e90f016cab552492e05f5cb5b52de6463@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: don't enter idle during link switchJohannes Berg3-16/+22
When doing link switch with a disjoint set of links before and after the switch, we end up removing all channel contexts, adding new ones later. This looks like 'idle' to the code now, and we enter idle which also includes flushing queues. But we can't actually flush since we don't have a link active (bound to a channel context), and entering idle just to leave it again is also wrong. Fix this by passing through an indication that we shouldn't do any idle checks in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320091155.170328bac555.If4a522a9dd3133b91983854b909a4de13aa635da@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: add support for tearing down negotiated TTLMAyala Beker3-1/+81
In order to activate a link that is currently inactive due to a negotiated TTLM request, need to first tear down the negotiated TTLM request. Add support for sending TTLM teardown request and update the links state accordingly. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240318184907.d480cbf46fcf.Idedad472469d2c27dd2a088cf80a13a1e1cf9b78@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: improve association error reporting slightlyBenjamin Berg1-8/+10
There is no reason to check the request flags for each of the links, so pull that out of the loop. Also, within the loop we can set the per-link error everywhere. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240318184907.695faa9be279.I71b11a8d66a9cae4c27e242a47d1d92922609b03@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: add flag to disallow puncturing in 5 GHzJohannes Berg2-0/+5
Some devices may not be capable of handling puncturing in 5 GHz only (vs. the current flag that just removes puncturing support completely). Add a flag to support such devices: check and then downgrade the channel width if needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240318184907.49759510da7d.I12c5a61f0be512e0c4e574c2f794ef4b37ecaf6b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: handle indoor AFC/LPI AP on assoc successAnjaneyulu1-0/+2
Update power_type in bss_conf based on Indoor AFC and LPI power types received in HE 6 GHz operation element on assoc success. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240318184907.89c25dae34ff.Ifd8b2983f400623ac03dc032fc9a20025c9ca365@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: spectmgmt: simplify 6 GHz HE/EHT handlingJohannes Berg1-7/+7
Clean up the code here a bit to have only a single call to ieee80211_chandef_he_6ghz_oper() by using a local pointer variable for the difference. Link: https://msgid.link/20240312112048.94c421d767f9.Ia7ca2f315b392c74d39b44fa9eb872a2e62e75c1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: supplement parsing of puncturing bitmapKang Yang2-0/+6
Current mac80211 won't parsing puncturing bitmap when process EHT Operation element in 6 GHz band or Bandwidth Indication element. This leads to puncturing bitmap cannot be updated in related situations, such as connecting to an EHT AP in 6 GHz band. So supplement parsing of puncturing bitmap for these elements. Signed-off-by: Kang Yang <quic_kangyang@quicinc.com> Link: https://msgid.link/20240312045947.576231-2-quic_kangyang@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: correctly set active links upon TTLMAyala Beker1-1/+9
Fix ieee80211_ttlm_set_links() to not set all active links, but instead let the driver know that valid links status changed and select the active links properly. Fixes: 8f500fbc6c65 ("wifi: mac80211: process and save negotiated TID to Link mapping request") Signed-off-by: Ayala Beker <ayala.beker@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240318184907.acddbbf39584.Ide858f95248fcb3e483c97fcaa14b0cd4e964b10@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: fix prep_connection error pathJohannes Berg1-2/+3
If prep_channel fails in prep_connection, the code releases the deflink's chanctx, which is wrong since we may be using a different link. It's already wrong to even do that always though, since we might still have the station. Remove it only if prep_channel succeeded and later updates fail. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240318184907.2780c1f08c3d.I033c9b15483933088f32a2c0789612a33dd33d82@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: fix ieee80211_bss_*_flags kernel-docJeff Johnson1-2/+2
Running kernel-doc on ieee80211_i.h flagged the following: net/mac80211/ieee80211_i.h:145: warning: expecting prototype for enum ieee80211_corrupt_data_flags. Prototype was for enum ieee80211_bss_corrupt_data_flags instead net/mac80211/ieee80211_i.h:162: warning: expecting prototype for enum ieee80211_valid_data_flags. Prototype was for enum ieee80211_bss_valid_data_flags instead Fix these warnings. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://msgid.link/20240314-kdoc-ieee80211_i-v1-1-72b91b55b257@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changesFelix Fietkau1-3/+2
When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change. Cc: stable@vger.kernel.org Reported-by: ranygh@riseup.net Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://msgid.link/20240316074336.40442-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: mac80211: fix mlme_link_id_dbg()Johan Hovold1-1/+1
Make sure that the new mlme_link_id_dbg() macro honours CONFIG_MAC80211_MLME_DEBUG as intended to avoid spamming the log with messages like: wlan0: no EHT support, limiting to HE wlan0: determined local STA to be HE, BW limited to 160 MHz wlan0: determined AP xx:xx:xx:xx:xx:xx to be VHT wlan0: connecting with VHT mode, max bandwidth 160 MHz Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/20240325085948.26203-1-johan+linaro@kernel.org Tested-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-08Merge tag 'wireless-next-2024-03-08' of ↵Jakub Kicinski19-295/+433
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.9 The fourth "new features" pull request for v6.9 with changes both in stack and in drivers. The theme in this pull request is to fix sparse warnings but we still have some left in wireless subsystem. Otherwise quite normal. Major changes: rtw89 * NL80211_EXT_FEATURE_SCAN_RANDOM_SN support * NL80211_EXT_FEATURE_SET_SCAN_DWELL support rtw88 * support for more rtw8811cu and rtw8821cu devices mt76 * mt76x2u: add Netgear WNDA3100v3 USB * mt7915: newer ADIE version support * mt7925: radio temperature sensor support * mt7996: remove GCMP IGTK offload * tag 'wireless-next-2024-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (125 commits) wifi: rtw89: wow: move release offload packet earlier for WoWLAN mode wifi: rtw89: wow: set security engine options for 802.11ax chips only wifi: rtw89: update suspend/resume for different generation wifi: rtw89: wow: update config mac function with different generation wifi: rtw89: update DMA function with different generation wifi: rtw89: wow: update WoWLAN status register for different generation wifi: rtw89: wow: update WoWLAN reason register for different chips wifi: brcm80211: handle pmk_op allocation failure wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERR wifi: rtw89: coex: When Bluetooth not available don't set power/gain wifi: rtw89: coex: add return value to ensure H2C command is success or not wifi: rtw89: coex: Reorder H2C command index to align with firmware wifi: rtw89: coex: add BTC ctrl_info version 7 and related logic wifi: rtw89: coex: add init_info H2C command format version 7 wifi: rtw89: 8922a: add coexistence helpers of SW grant wifi: rtw89: mac: add coexistence helpers {cfg/get}_plt wifi: cw1200: restore endian swapping wifi: wlcore: sdio: Rate limit wl12xx_sdio_raw_{read,write}() failures warns wifi: rtlwifi: Remove rtl_intf_ops.read_efuse_byte wifi: rtw88: 8821c: Fix false alarm count ... ==================== Link: https://lore.kernel.org/r/20240308100429.B8EA2C433F1@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-04wifi: mac80211: remove TDLS peers on link deactivationJohannes Berg1-1/+1
If a link is deactivated, we really cannot sustain any TDLS connections on that link any more. With the API now changed, fix this issue and remove TDLS connections. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://msgid.link/20240228095719.a7dd812c37bf.I3474dbde79e9e7a539d47f6f81f32e6c3e459080@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: remove TDLS peers only on affected linkJohannes Berg4-6/+11
If a link does CSA, or if it changes SMPS mode, we need to drop the TDLS peers, but we really should drop them only on the affected link. Fix that. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://msgid.link/20240228095719.00d1d793f5b8.Ia9971316c6b3922dd371d64ac2198f91ed5ad9d2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: mlme: unify CSA handlingJohannes Berg1-16/+22
Unify all the CSA handling, including handling of a beacon after the CSA, into ieee80211_sta_process_chanswitch(). The CRC of the beacon will change due to changes in the CSA/ECSA elements, so there's really no need to have the 'beacon after CSA' handling before the CRC processing or to change the beacon_crc_valid value here. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228095719.e269c0e02905.I9dc68ff1e84d51349822bc7d3b33b578fcf8e360@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: introduce a feature flag for quiet in CSAJohannes Berg5-26/+37
When doing CSA in multi-link, there really isn't a need to stop transmissions entirely. Add a feature flag for drivers to indicate they can handle quiet in CSA (be it by parsing themselves, or by implementing drv_pre_channel_switch()), to make that possible. Also clean up the csa_block_tx handling: it clearly cannot handle multi-link due to the way queues are stopped, move it to the sdata. Drivers should be doing it themselves for working properly during CSA in MLO anyway. Also rename it to indicate that it reflects TX was blocked at mac80211. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228095719.258439191541.I2469d206e2bf5cb244cfde2b4bbc2ae6d1cd3dd9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: pass link conf to abort_channel_switchJohannes Berg2-4/+6
Pass the link conf to the abort_channel_switch driver method so the driver can handle things correctly. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228095718.27f621106ddd.Iadd3d69b722ffe5934779a32a0e4e596a4e33ed4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: pass link_id to channel switch opsJohannes Berg3-66/+24
For CSA to work correctly in multi-link scenarios, pass the link_id to the relevant callbacks. While at it, unify/deduplicate the tracing for them. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://msgid.link/20240228095718.b7726635c054.I0be5d00af4acb48cfbd23a9dbf067f9aeb66469d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: hide element parsing internalsJohannes Berg3-58/+78
Rework the data structures to hide element parsing internals from the users. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228094902.19c610b529e2.Ie7ea2dcb6713911590ace6583a4748f32dc37df2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>