summaryrefslogtreecommitdiff
path: root/net/mac80211/cfg.c
AgeCommit message (Collapse)AuthorFilesLines
2024-07-26wifi: mac80211: use monitor sdata with driver only if desiredJohannes Berg1-2/+5
In commit 0d9c2beed116 ("wifi: mac80211: fix monitor channel with chanctx emulation") I changed mac80211 to always have an internal monitor_sdata to have something to have the chanctx bound to. However, if the driver didn't also have the WANT_MONITOR flag this would cause mac80211 to allocate it without telling the driver (which was intentional) but also use it for later APIs to the driver without it ever having known about it which was _not_ intentional. Check through the code and only use the monitor_sdata in the relevant places (TX, MU-MIMO follow settings, TX power, and interface iteration) when the WANT_MONITOR flag is set. Cc: stable@vger.kernel.org Fixes: 0d9c2beed116 ("wifi: mac80211: fix monitor channel with chanctx emulation") Reported-by: ZeroBeat <ZeroBeat@gmx.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219086 Tested-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20240725184836.25d334157a8e.I02574086da2c5cf0e18264ce5807db6f14ffd9c0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: extend ifcomb check functions for multi-radioFelix Fietkau1-3/+4
Add support for counting global and per-radio max/current number of channels, as well as checking radio-specific interface combinations. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/e76307f8ce562a91a74faab274ae01f6a5ba0a2e.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-28wifi: mac80211: remove key data from get_key callbackJohannes Berg1-3/+0
This is now unused in nl80211, so there's no need to set the pointer/length. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240627104411.f8ac49a8cfe0.Ic01f775903f0acd10b9ba77eb39d4ed50e709173@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-26wifi: mac80211: refactor CSA queue block/unblockJohannes Berg1-16/+4
This code is duplicated many times, refactor it into new separate functions. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240612143037.1ad22f10392d.If21490c2c67aae28f3c54038363181ee920ce3d1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-12wifi: mac80211: clean up 'ret' in sta_link_apply_parameters()Johannes Berg1-2/+3
There's no need to have the always-zero ret variable in the function scope, move it into the inner scope only. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605135233.eb7a24632d98.I72d7fe1da89d4b89bcfd0f5fb9057e3e69355cfe@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-12wifi: mac80211: fix erroneous errors for STA changesJohannes Berg1-19/+36
When e.g. wpa_supplicant sets only the MLD "sta" authorized state, the code actually applies that change, but then returns an error to userspace anyway because there were no changes to the link station, and no link ID was given. However, it's not incorrect to not have a link ID when wanting to change only the MLD peer ("sta") state, so the code shouldn't require it. To fix this, separate the "new_link" argument out into a new three-state enum, because if modify is called on a link STA only, it should return an error if no link is given or if it doesn't exist. For modify on the MLD "sta", not having a link ID is OK, but if there is one it should be validated. This seems to not have mattered much as wpa_supplicant just prints a message and continues, and the authorized state was already set before this error return. However, in the later code powersave recalculation etc. will be skipped, so that it may result in never allowing powersave on MLO connections. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605135233.48e2b8af07e3.Ib9793c383fcba118c05100e024f4a11a1c3d0e85@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-11Merge tag 'wireless-next-2024-06-07' of ↵Jakub Kicinski1-51/+29
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.11 The first "new features" pull request for v6.11 with changes both in stack and in drivers. Nothing out of ordinary, except that we have two conflicts this time: net/mac80211/cfg.c https://lore.kernel.org/all/20240531124415.05b25e7a@canb.auug.org.au drivers/net/wireless/microchip/wilc1000/netdev.c https://lore.kernel.org/all/20240603110023.23572803@canb.auug.org.au Major changes: cfg80211/mac80211 * parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers wilc1000 * read MAC address during probe to make it visible to user space iwlwifi * bump FW API to 91 for BZ/SC devices * report 64-bit radiotap timestamp * enable P2P low latency by default * handle Transmit Power Envelope (TPE) advertised by AP * start using guard() rtlwifi * RTL8192DU support ath12k * remove unsupported tx monitor handling * channel 2 in 6 GHz band support * Spatial Multiplexing Power Save (SMPS) in 6 GHz band support * multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support * dynamic VLAN support * add panic handler for resetting the firmware state ath10k * add qcom,no-msa-ready-indicator Device Tree property * LED support for various chipsets * tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits) wifi: ath12k: add hw_link_id in ath12k_pdev wifi: ath12k: add panic handler wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity() wifi: brcm80211: remove unused structs wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type) wifi: ath12k: do not process consecutive RDDM event dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup() wifi: rtlwifi: handle return value of usb init TX/RX wifi: rtlwifi: Enable the new rtl8192du driver wifi: rtlwifi: Add rtl8192du/sw.c wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg wifi: rtlwifi: Add rtl8192du/dm.{c,h} wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h} wifi: rtlwifi: Add rtl8192du/rf.{c,h} wifi: rtlwifi: Add rtl8192du/trx.{c,h} wifi: rtlwifi: Add rtl8192du/phy.{c,h} wifi: rtlwifi: Add rtl8192du/hw.{c,h} wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU wifi: rtlwifi: Add rtl8192du/table.{c,h} ... Signed-off-by: Jakub Kicinski <kuba@kernel.org> ==================== Link: https://lore.kernel.org/r/20240607093517.41394C2BBFC@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-05-29wifi: mac80211: pass proper link id for channel switch started notificationAditya Kumar Singh1-2/+2
Original changes[1] posted is having proper changes. However, at the same time, there was chandef puncturing changes which had a conflict with this. While applying, two errors crept in - a) Whitespace error. b) Link ID being passed to channel switch started notifier function is 0. However proper link ID is present in the function. Fix these now. [1] https://lore.kernel.org/all/20240130140918.1172387-5-quic_adisi@quicinc.com/ Fixes: 1a96bb4e8a79 ("wifi: mac80211: start and finalize channel switch on link basis") Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240509032555.263933-1-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-29wifi: mac80211: apply mcast rate only if interface is upJohannes Berg1-2/+3
If the interface isn't enabled, don't apply multicast rate changes immediately. Reported-by: syzbot+de87c09cc7b964ea2e23@syzkaller.appspotmail.com Link: https://msgid.link/20240515133410.d6cffe5756cc.I47b624a317e62bdb4609ff7fa79403c0c444d32d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: mac80211: Add EHT UL MU-MIMO flag in ieee80211_bss_confPradeep Kumar Chitrapu1-0/+5
Add flag for Full Bandwidth UL MU-MIMO for EHT. This is utilized to pass EHT MU-MIMO configurations from user space to driver in AP mode. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> Link: https://msgid.link/20240515181327.12855-2-quic_pradeepc@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: mac80211: collect some CSA data into sub-structsJohannes Berg1-8/+8
Collect the CSA data in ieee80211_link_data_managed and ieee80211_link_data into a csa sub-struct to clean up a bit and make adding new things more obvious. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240506215543.29f954b1f576.I9a683a9647c33d4dd3011aade6677982428c1082@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: mac80211: move radar detect work to sdataJohannes Berg1-3/+3
At some point we thought perhaps this could be per link, but really that didn't happen, and it's confusing. Radar detection still uses the deflink to allocate the channel, but the work need not be there. Move it back. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240506211311.43bd82c6da04.Ib39bec3aa198d137385f081e7e1910dcbde3aa1b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: mac80211: remove extra link STA functionsJohannes Berg1-36/+13
There's no need to have a lockdep assert and then call another function, just move everything into one place. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240506211934.9759564a25f4.I88d43aa459d15c1d6230152e76b7757c2cdd6085@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: mac80211: remove outdated commentsJohannes Berg1-4/+0
These comments are no longer correct, it's a wiphy work now so it will go away immediately when canceled. Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240506211422.68bc10efbd8a.If80f43f4c8b9db1f5266f70d93a805f8c7463fe2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-03wifi: mac80211: handle color change per linkAditya Kumar Singh1-46/+98
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-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: transmit deauth only if link is availableJohannes Berg1-6/+6
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-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-04wifi: mac80211: remove TDLS peers only on affected linkJohannes Berg1-1/+1
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: introduce a feature flag for quiet in CSAJohannes Berg1-7/+9
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_id to channel switch opsJohannes Berg1-1/+3
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: add ieee80211_vif_link_active() helperJohannes Berg1-2/+1
We sometimes need to check if a link is active, and this is complicated by the fact that active_links has no bits set when the vif isn't (acting as) an MLD. Add a small new helper ieee80211_vif_link_active() to make that a bit easier, and use it in a few places. Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228094901.688760aff5f7.I06892a503f5ecb9563fbd678d35d08daf7a044b0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: Adjust CQM handling for MLOIlan Peer1-29/+50
The CQM handling did not consider the MLO case and thus notified a not-existing link with the CQM change. To fix this, propagate the CQM notification to all the active links (handling both the non-MLO and MLO cases). TODO: this currently propagates the same configuration to all links regardless of the band. This might not be the correct approach as different links might need to be configured with different values. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228094753.bf6a3fefe553.Id738810b73e1087e01d5885508b70a3631707627@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: handle netif carrier up/down with link AP during MLOAditya Kumar Singh1-2/+30
Currently whenever link AP is started, netif_carrier_up() function is called and whenever it is brought down, netif_carrier_down() function is called. However, with MLO, all the links of the same MLD would use the same netdev. Hence there is no need to indicate for each link up/down. Also, calling it down when only one of the links went down is not desirable. Add changes to call the netif_carrier_up() function only when first link is brought up. Similarly, add changes to call the netif_carrier_down() function only when last link is brought down. In order to check the number of beaconing links in the given interface, introduce a new helper function ieee80211_num_beaconing_links(). Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240227042251.1511122-3-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: remove only link keys during stopping link APRameshkumar Sundaram1-1/+7
Currently while stopping a link AP, all keys from the interface were removed. However with MLO there is a requirement to free only the link keys. Add changes to remove keys which are associated with the link AP which is going to be stopped. Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240227042251.1511122-2-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: track capability/opmode NSS separatelyJohannes Berg1-1/+1
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 <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228120157.0e1c41924d1d.I0acaa234e0267227b7e3ef81a59117c8792116bc@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: remove only own link stations during stop_apAditya Kumar Singh1-1/+1
Currently, whenever AP link is brought down via ieee80211_stop_ap() function, all stations connected to the sdata are flushed. However, in case of MLO there is a requirement to flush only stations connected to that link and not all. For instance - Consider 2 GHz and 5 GHz are AP MLD. Now due to some reason 5 GHz link of this AP is going down (link removal or any other case). All stations connected, even legacy stations connected to 2 GHz link AP would also be flushed. Flushing of other link stations is not desirable. Fix this issue by passing self link ID to sta_flush() function. This would then only remove the stations which are still using the passed link ID as their link sta. Other stations will not be affected. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-4-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: flush only stations using requests linksAditya Kumar Singh1-2/+2
Whenever sta_flush() function is invoked, all STAs present in that interface are flushed. In case of MLO, it is desirable to only flush such STAs that are at least using a given link id as one of their links. Add support for this by making change in the __sta_info_flush API argument to accept a link ID. And then, only if the STA is using the given link as one of its links, it would be flushed. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-3-quic_adisi@quicinc.com [reword commit message, in particular this isn't about "active" links] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: remove gfp parameter from ieee80211_obss_color_collision_notifyLorenzo Bianconi1-1/+1
Get rid of gfp parameter from ieee80211_obss_color_collision_notify since it is no longer used. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://msgid.link/f91e1c78896408ac556586ba8c99e4e389aeba02.1707389901.git.lorenzo@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: add support to call csa_finish on a linkAditya Kumar Singh1-2/+13
Currently ieee80211_csa_finish() function finalizes CSA by scheduling a finalizing worker using the deflink. With MLO, there is a need to do it on a given link basis. Pass link ID of the link on which CSA needs to be finalized. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-6-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: start and finalize channel switch on link basisAditya Kumar Singh1-24/+35
Add changes to start a channel switch as well as finalize it on link basis in order to support CSA with MLO as well. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-5-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: handle set csa/after_csa beacon on per link basisAditya Kumar Singh1-13/+15
In order to support CSA with MLO, there is a need to handle the functions ieee80211_set_csa_beacon() and ieee80211_set_after_csa_beacon() on a per link basis. Implement this by making the function argument accept the the link data instead of the sdata. Currently, deflink would only be passed. Proper link data will be passed in a subsequent patch. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-4-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: allow CSA to same channelJohannes Berg1-4/+0
This could be used e.g. for temporarily sending quiet (mode=1 in CSA/ECSA), or updating bandwidth. This is also useful for testing, since it's something that an AP may do and the client needs to be prepared. Simply allow it. Link: https://msgid.link/20240129203544.ef7258d5790d.Idafe22e41621757458d4960659b9621853f7104d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: cfg80211/mac80211: move puncturing into chandefJohannes Berg1-16/+5
Aloka originally suggested that puncturing should be part of the chandef, so that it's treated correctly. At the time, I disagreed and it ended up not part of the chandef, but I've now realized that this was wrong. Even for clients, the RX, and perhaps more importantly, CCA configuration needs to take puncturing into account. Move puncturing into the chandef, and adjust all the code accordingly. Also add a few tests for puncturing in chandef compatibility checking. Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/ Suggested-by: Aloka Dixit <quic_alokad@quicinc.com> Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: introduce 'channel request'Johannes Berg1-28/+38
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 <johannes.berg@intel.com>
2024-02-08wifi: mac80211: simplify non-chanctx driversJohannes Berg1-24/+18
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 <johannes.berg@intel.com>
2024-02-08Merge wireless into wireless-nextJohannes Berg1-7/+9
There are some changes coming to wireless-next that will otherwise cause conflicts, pull wireless in first to be able to resolve that when applying the individual changes rather than having to do merge resolution later. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: mac80211: clean up FILS discovery change flags handlingJohannes Berg1-6/+6
It doesn't make sense to return BSS change flags in an int, as they're a bigger type. For this particular function it still works OK, but clean it up to avoid future errors (or copying this code in a broken way.) Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://msgid.link/20240129195739.e340a7d5e7c6.I1dfcca32d43dce903494a2c474844491682671b4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: mac80211: fix unsolicited broadcast probe configJohannes Berg1-7/+7
There's a bug in ieee80211_set_unsol_bcast_probe_resp(), it tries to return BSS_CHANGED_UNSOL_BCAST_PROBE_RESP (which has the value 1<<31) in an int, which makes it negative and considered an error. Fix this by passing the changed flags to set separately. Fixes: 3b1c256eb4ae ("wifi: mac80211: fixes in FILS discovery updates") Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://msgid.link/20240129195729.965b0740bf80.I6bc6f5236863f686c17d689be541b1dd2633c417@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: mac80211: set station RX-NSS on reconfigJohannes Berg1-0/+2
When a station is added/reconfigured by userspace, e.g. a TDLS peer or a SoftAP client STA, rx_nss is currently not always set, so that it might be left zero. Set it up properly. Link: https://msgid.link/20240129155354.98f148a3d654.I193a02155f557ea54dc9d0232da66cf96734119a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-01-26wifi: mac80211: add support for SPP A-MSDUsJohannes Berg1-0/+3
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 <johannes.berg@intel.com> Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240102213313.b8ada4514e2b.I1ac25d5f158165b5a88062a5a5e4c4fbeecf9a5d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-01-26wifi: mac80211: add support for negotiated TTLM requestAyala Beker1-0/+12
Update neg_ttlm and active_links according to the new mapping, and send a negotiated TID-to-link map request with the new mapping. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240102213313.eeb385d771df.I2a5441c14421de884dbd93d1624ce7bb2c944833@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-12-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni1-2/+2
Cross-merge networking fixes after downstream PR. Adjacent changes: drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c 23c93c3b6275 ("bnxt_en: do not map packet buffers twice") 6d1add95536b ("bnxt_en: Modify TX ring indexing logic.") tools/testing/selftests/net/Makefile 2258b666482d ("selftests: add vlan hw filter tests") a0bc96c0cd6e ("selftests: net: verify fq per-band packet limit") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-12wifi: mac80211: Replace ENOTSUPP with EOPNOTSUPPAndrei Otcheretianski1-2/+2
ENOTSUP isn't a standard error code. EOPNOTSUPP should be used instead. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231211085121.3841b71c867d.Idf2ad01d9dfe8d6d6c352bf02deb06e49701ad1d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-12-12wifi: mac80211: check if the existing link config remains unchangedEdward Adam Davis1-2/+2
[Syz report] WARNING: CPU: 1 PID: 5067 at net/mac80211/rate.c:48 rate_control_rate_init+0x540/0x690 net/mac80211/rate.c:48 Modules linked in: CPU: 1 PID: 5067 Comm: syz-executor413 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:rate_control_rate_init+0x540/0x690 net/mac80211/rate.c:48 Code: 48 c7 c2 00 46 0c 8c be 08 03 00 00 48 c7 c7 c0 45 0c 8c c6 05 70 79 0b 05 01 e8 1b a0 6f f7 e9 e0 fd ff ff e8 61 b3 8f f7 90 <0f> 0b 90 e9 36 ff ff ff e8 53 b3 8f f7 e8 5e 0b 78 f7 31 ff 89 c3 RSP: 0018:ffffc90003c57248 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888016bc4000 RCX: ffffffff89f7d519 RDX: ffff888076d43b80 RSI: ffffffff89f7d6df RDI: 0000000000000005 RBP: ffff88801daaae20 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000001 R13: 0000000000000000 R14: ffff888020030e20 R15: ffff888078f08000 FS: 0000555556b94380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 0000000076d22000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sta_apply_auth_flags.constprop.0+0x4b7/0x510 net/mac80211/cfg.c:1674 sta_apply_parameters+0xaf1/0x16c0 net/mac80211/cfg.c:2002 ieee80211_add_station+0x3fa/0x6c0 net/mac80211/cfg.c:2068 rdev_add_station net/wireless/rdev-ops.h:201 [inline] nl80211_new_station+0x13ba/0x1a70 net/wireless/nl80211.c:7603 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2545 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x93c/0xe40 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b [Analysis] It is inappropriate to make a link configuration change judgment on an non-existent and non new link. [Fix] Quickly exit when there is a existent link and the link configuration has not changed. Fixes: b303835dabe0 ("wifi: mac80211: accept STA changes without link changes") Reported-and-tested-by: syzbot+62d7eef57b09bfebcd84@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://msgid.link/tencent_DE67FF86DB92ED465489A36ECD2EDDCC8C06@qq.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: mac80211: Rename and update IEEE80211_VIF_DISABLE_SMPS_OVERRIDEIlan Peer1-0/+6
EMLSR operation and SMPS operation cannot coexist. Thus, when EMLSR is enabled, all SMPS signaling towards the AP should be stopped (it is expected that the AP will consider SMPS to be off). Rename IEEE80211_VIF_DISABLE_SMPS_OVERRIDE to IEEE80211_VIF_EML_ACTIVE and use the flag as an indication from the driver that EMLSR is enabled. When EMLSR is enabled SMPS flows towards the AP MLD should be stopped. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230928172905.fb2c2f9a0645.If6df5357568abd623a081f0f33b07e63fb8bba99@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-06Merge wireless into wireless-nextJohannes Berg1-2/+9
Resolve several conflicts, mostly between changes/fixes in wireless and the locking rework in wireless-next. One of the conflicts actually shows a bug in wireless that we'll want to fix separately. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org>
2023-09-25wifi: mac80211: update the rx_chains after set_antenna()Emmanuel Grumbach1-1/+7
rx_chains was set only upon registration and it we rely on it for the active chains upon SMPS configuration after association. When we use the set_antenna() API to limit the rx_chains from 2 to 1, this caused issues with iwlwifi since we still had 2 active_chains requested. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.2dde4da246b2.I904223c868c77cf2ba132a3088fe6506fcbb443b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: cfg80211: split struct cfg80211_ap_settingsJohannes Berg1-1/+1
Using the full struct cfg80211_ap_settings for an update is misleading, since most settings cannot be updated. Split the update case off into a new struct cfg80211_ap_update. Change-Id: I3ba4dd9280938ab41252f145227a7005edf327e4 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-03 11:10:41 +0300