- 21 Feb, 2024 4 commits
-
-
Jeff Johnson authored
In [1] it was observed that the ath12k maintainers were not added to the review of a new ath12k YAML file. Bartosz suggested "adding an N: ath12k entry to MAINTAINERS" to prevent this in the future. In the process it was noticed that one of the ath11k YAML files was also not explicitly referenced, so add N: entries to ath10k, ath11k, and ath12k, and remove the explicit F: entries. Link: https://lore.kernel.org/linux-wireless/20240216203215.40870-7-brgl@bgdev.pl/ [1] Suggested-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240217-update-maintainer-v1-2-1426cf7a8bb1@quicinc.com
-
Jeff Johnson authored
I now have a @kernel.org e-mail address, so use that for my maintenance activities. Signed-off-by:
-
Emmanuel Grumbach authored
Those devices' fifos are numbered differently. Because of that, we were looking at the size of the VO fifo size to determine the size of the A-MSDU which led to a lower throughput. Note that for those devices the only user of the AC -> fifo mapping is the size limitation of A-MSDU. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240218194912.da336ca2fa0a.I73e44d5fc474ebb6f275b9008950e59c012f33b2@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Benjamin Berg authored
The resume code path assumes that the TX queue for the offloading TID has been configured. At resume time it then tries to sync the write pointer as it may have been updated by the firmware. In the unusual event that no packets have been send on TID 0, the queue will not have been allocated and this causes a crash. Fix this by ensuring the queue exist at suspend time. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
- 15 Feb, 2024 1 commit
-
-
Johannes Berg authored
It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID. Cc: stable@vger.kernel.org Fixes: 29cbe68c ("cfg80211/mac80211: add mesh join/leave commands") Reported-by: syzbot+dd4779978217b1973180@syzkaller.appspotmail.com Signed-off-by:
-
- 08 Feb, 2024 6 commits
-
-
Emmanuel Grumbach authored
A DoS tool that injects loads of authentication frames made our AP crash. The iwl_mvm_is_dup() function couldn't find the per-queue dup_data which was not allocated. The root cause for that is that we ran out of stations in the firmware and we didn't really add the station to the firmware, yet we didn't return an error to mac80211. Mac80211 was thinking that we have the station and because of that, sta_info::uploaded was set to 1. This allowed ieee80211_find_sta_by_ifaddr() to return a valid station object, but that ieee80211_sta didn't have any iwl_mvm_sta object initialized and that caused the crash mentioned earlier when we got Rx on that station. Cc: stable@vger.kernel.org Fixes: 57974a55 ("wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()") Signed-off-by:
-
Dan Carpenter authored
This is an error path and Smatch complains that "tbl_rev" is uninitialized on this path. All the other functions follow this same patter where they set the error code and goto out_free so that's probably what was intended here as well. Fixes: e8e10a37 ("iwlwifi: acpi: move ppag code from mvm to fw/acpi") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://msgid.link/09900c01-6540-4a32-9451-563da0029cb6@moroto.mountainSigned-off-by:
-
Dan Carpenter authored
This saves the error as PTR_ERR(wifi_pkg). The problem is that "wifi_pkg" is a valid pointer, not an error pointer. Set the error code to -EINVAL instead. Fixes: 2a808414 ("iwlwifi: acpi: support reading and storing WRDS revision 1 and 2") Signed-off-by:
-
Miri Korenblit authored
Before sending a SESSION PROTECTION cmd the driver checks if the link_id indicated in the time event (and for which the cmd will be sent) is valid and exists. Clear the te_data::link_id when FW notifies that a session protection ended, so the check will actually fail when it should. Fixes: 13506583 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION cmd") Signed-off-by:
-
Daniel Gabay authored
As described in IEEE sta 802.11-2020, table 9-30 (Address field contents), A-MSDU address 3 should contain the BSSID address. In TX_CMD we copy the MAC header from skb, and skb address 3 holds the destination address, but it may not be identical to the BSSID. Using the wrong destination address appears to work with (most) receivers without MLO, but in MLO some devices are checking for it carefully, perhaps as a consequence of link to MLD address translation. Replace address 3 in the TX_CMD MAC header with the correct address while retaining the skb address 3 unchanged. This ensures that skb address 3 will be utilized later for constructing the A-MSDU subframes. Note that we fill in the MLD address, but the firmware will do the necessary translation to link address after encryption. Signed-off-by:
Daniel Gabay <daniel.gabay@intel.com> Signed-off-by:
-
Johannes Berg authored
This pointer can change here since the SKB can change, so we actually later open-coded IEEE80211_SKB_CB() again. Reload the pointer where needed, so the monitor-mode case using it gets fixed, and then use info-> later as well. Cc: stable@vger.kernel.org Fixes: 53168215 ("mac80211: fix VLAN handling with TXQs") Link: https://msgid.link/20240131164910.b54c28d583bc.I29450cec84ea6773cff5d9c16ff92b836c331471@changeidSigned-off-by:
-
- 05 Feb, 2024 1 commit
-
-
Felix Fietkau authored
Copy cck and ofdm separately in order to avoid __read_overflow2_field warning. Fixes: f75e4779 ("wifi: mt76: mt7996: add txpower setting support") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
- 02 Feb, 2024 14 commits
-
-
Kees Cook authored
After commit e3eac9f3 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by"), the compiler may enforce dynamic array indexing of req->channels to stay below n_channels. As a result, n_channels needs to be increased _before_ accessing the newly added array index. Increment it first, then use "i" for the prior index. Solves this warning in the coming GCC that has __counted_by support: ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 'brcmf_internal_escan_add_info': ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:3783:46: warning: operation on 'req-> n_channels' may be undefined [-Wsequence-point] 3783 | req->channels[req->n_channels++] = chan; | ~~~~~~~~~~~~~~~^~ Fixes: e3eac9f3 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Cc: Arend van Spriel <aspriel@gmail.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Chi-hsien Lin <chi-hsien.lin@infineon.com> Cc: Ian Lin <ian.lin@infineon.com> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Wright Feng <wright.feng@cypress.com> Cc: Hector Martin <marcan@marcan.st> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Benjamin Berg authored
mac80211 does not have proper support for EPCS currently as that would require changing the ECDA parameters if EPCS (Emergency Preparedness Communications Service) is in use. As such, do not announce support for it in the capabilities. Signed-off-by:
-
Miri Korenblit authored
Currently the driver exits eSR by calling iwl_mvm_esr_mode_inactive() before updating the FW (by deactivating one of the links), and therefore before sending the EML frame notifying that we are no longer in eSR. This is wrong for several reasons: 1. The driver sends SMPS activation frames when we are still in eSR and SMPS should be disabled when in eSR 2. The driver restores RLC configuration as it was before eSR entering, and RLC command shouldn't be sent in eSR Fix this by calling iwl_mvm_esr_mode_inactive() after FW update Fixes: 12bacfc2 ("wifi: iwlwifi: handle eSR transitions") Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Reviewed-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.d8d9dc277d4e.Ib5aee0fd05e35b1da7f18753eb3c8fa0a3f872f3@changeidSigned-off-by:
-
Emmanuel Grumbach authored
Fix the DBG_CONFIG_TOKEN to not enable debug components that would prevent the device to save power. Fixes: fc2fe0a5 ("wifi: iwlwifi: fw: disable firmware debug asserts") Cc: stable@vger.kernel.org Signed-off-by:
Eilon Rinat <eilon.rinat@intel.com> Reviewed-by:
-
Johannes Berg authored
On the 6 GHz band, probe responses are sent as broadcast to optimise medium usage. However, without OCE configuration we weren't accepting them, which is wrong, even if wpa_s is by default enabling OCE. Accept them without the OCE config as well. Link: https://msgid.link/20240129200907.5a89c2821897.I92e9dfa0f9b350bc7f37dd4bb38031d156d78d8a@changeidSigned-off-by:
-
Johannes Berg authored
There's a call to drv_mgd_prepare_tx() and so there should be one to drv_mgd_complete_tx(), but on this path it's not. Add it. Link: https://msgid.link/20240131164824.2f0922a514e1.I5aac89b93bcead88c374187d70cad0599d29d2c8@changeidSigned-off-by:
-
Johannes Berg authored
This should be waiting if we don't have a beacon yet, but somehow I managed to invert the logic. Fix that. Fixes: 74e1309a ("wifi: mac80211: mlme: look up beacon elems only if needed") Link: https://msgid.link/20240131164856.922701229546.I239b379e7cee04608e73c016b737a5245e5b23dd@changeidSigned-off-by:
-
Johannes Berg authored
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: 3b1c256e ("wifi: mac80211: fixes in FILS discovery updates") Reviewed-by:
-
Johannes Berg authored
The SMPS mode is currently re-initialized too late, since ieee80211_prep_channel() can be called again after we've already done ieee80211_setup_assoc_link(), in case there's some override of the channel configuration. Fix this. Link: https://msgid.link/20240129195405.d6d74508be18.I0a7303b1ce4d8e5436011951ab624372a445c069@changeidSigned-off-by:
-
Johannes Berg authored
If a driver implements the change_interface() method, we switch interface type without taking the interface down, but still will recreate the debugfs for it since it's a new type. As such, we should use the ieee80211_debugfs_recreate_netdev() function here to also recreate the driver's files, if it is indeed from a type change while up. Link: https://msgid.link/20240129155402.7311a36ffeeb.I18df02bbeb685d4250911de5ffbaf090f60c3803@changeidSigned-off-by:
-
Johannes Berg authored
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@changeidSigned-off-by:
-
Johannes Berg authored
This looks up the link under RCU protection, but isn't guaranteed to actually have protection. Fix that. Fixes: 8cc07265 ("wifi: mac80211: handle TDLS data frames with MLO") Link: https://msgid.link/20240129155348.8a9c0b1e1d89.I553f96ce953bb41b0b877d592056164dec20d01c@changeidSigned-off-by:
-
Johannes Berg authored
As mentioned in the previous commit, we pretty quickly found that some APs have ECSA elements stuck in their probe response, so using that to not attempt to connect while CSA is happening we never connect to such an AP. Improve this situation by checking more carefully and ignoring the ECSA if cfg80211 has previously detected the ECSA element being stuck in the probe response. Additionally, allow connecting to an AP that's switching to a channel it's already using, unless it's using quiet mode. In this case, we may just have to adjust bandwidth later. If it's actually switching channels, it's better not to try to connect in the middle of that. Reported-by:
coldolt <andypalmadi@gmail.com> Closes: https://lore.kernel.org/linux-wireless/CAJvGw+DQhBk_mHXeu6RTOds5iramMW2FbMB01VbKRA4YbHHDTA@mail.gmail.com/ Fixes: c09c4f31 ("wifi: mac80211: don't connect to an AP while it's in a CSA process") Reviewed-by:
-
Johannes Berg authored
We recently added some validation that we don't try to connect to an AP that is currently in a channel switch process, since that might want the channel to be quiet or we might not be able to connect in time to hear the switching in a beacon. This was in commit c09c4f31 ("wifi: mac80211: don't connect to an AP while it's in a CSA process"). However, we promptly got a report that this caused new connection failures, and it turns out that the AP that we now cannot connect to is permanently advertising an extended channel switch announcement, even with quiet. The AP in question was an Asus RT-AC53, with firmware 3.0.0.4.380_10760-g21a5898. As a first step, attempt to detect that we're dealing with such a situation, so mac80211 can use this later. Reported-by:
-
- 01 Feb, 2024 1 commit
-
-
Johannes Berg authored
This no longer exists, remove the kernel-doc. Signed-off-by:
-
- 31 Jan, 2024 9 commits
-
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the MediaTek mt76 drivers. Here is a sorted list of descriptions. It might make the reviewing process easier. MODULE_DESCRIPTION("MediaTek MT7603E and MT76x8 wireless driver"); MODULE_DESCRIPTION("MediaTek MT7615E and MT7663E wireless driver"); MODULE_DESCRIPTION("MediaTek MT7615E MMIO helpers"); MODULE_DESCRIPTION("MediaTek MT7663 SDIO/USB helpers"); MODULE_DESCRIPTION("MediaTek MT7663S (SDIO) wireless driver"); MODULE_DESCRIPTION("MediaTek MT7663U (USB) wireless driver"); MODULE_DESCRIPTION("MediaTek MT76x02 helpers"); MODULE_DESCRIPTION("MediaTek MT76x02 MCU helpers"); MODULE_DESCRIPTION("MediaTek MT76x0E (PCIe) wireless driver"); MODULE_DESCRIPTION("MediaTek MT76x0U (USB) wireless driver"); MODULE_DESCRIPTION("MediaTek MT76x2 EEPROM helpers"); MODULE_DESCRIPTION("MediaTek MT76x2E (PCIe) wireless driver"); MODULE_DESCRIPTION("MediaTek MT76x2U (USB) wireless driver"); MODULE_DESCRIPTION("MediaTek MT76x connac layer helpers"); MODULE_DESCRIPTION("MediaTek MT76x EEPROM helpers"); MODULE_DESCRIPTION("MediaTek MT76x helpers"); MODULE_DESCRIPTION("MediaTek MT76x SDIO helpers"); MODULE_DESCRIPTION("MediaTek MT76x USB helpers"); MODULE_DESCRIPTION("MediaTek MT7915E MMIO helpers"); MODULE_DESCRIPTION("MediaTek MT7921 core driver"); MODULE_DESCRIPTION("MediaTek MT7921E (PCIe) wireless driver"); MODULE_DESCRIPTION("MediaTek MT7921S (SDIO) wireless driver"); MODULE_DESCRIPTION("MediaTek MT7921U (USB) wireless driver"); MODULE_DESCRIPTION("MediaTek MT7925 core driver"); MODULE_DESCRIPTION("MediaTek MT7925E (PCIe) wireless driver"); MODULE_DESCRIPTION("MediaTek MT7925U (USB) wireless driver"); MODULE_DESCRIPTION("MediaTek MT792x core driver"); MODULE_DESCRIPTION("MediaTek MT792x USB helpers"); MODULE_DESCRIPTION("MediaTek MT7996 MMIO helpers"); Signed-off-by:Breno Leitao <leitao@debian.org> Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Atmel WILC1000 SPI driver. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the TI WiLink 8 wireless driver. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Prism54 SPI wireless driver. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Qualcomm Atheros WCN3660/3680 wireless driver. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Atheros AR5523 wireless driver. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Broadcom FullMac WLAN drivers. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the TI wireless drivers wl12xx and wl1251. Signed-off-by:
-
Breno Leitao authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the TI WLAN wlcore drivers. Signed-off-by:
-
- 29 Jan, 2024 1 commit
-
-
Arend van Spriel authored
There has been some discussion about what is expected from a maintainer and so a cleanup seems to be in order. A dedicated mailing list has been created to discuss brcm80211 specific development issues. Keeping the status as Supported although help in maintaining this driver is welcomed. Cc: brcm80211@lists.linux.dev Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
- 26 Jan, 2024 3 commits
-
-
Mario Limonciello authored
Due to the way that debugging is used in the mac80211 subsystem this message ends up being noisier than it needs to be. As the statement is only useful at a first stage of triage for BIOS bugs, just drop it. Cc: Jun Ma <Jun.Ma2@amd.com> Suggested-by:
Mario Limonciello <mario.limonciello@amd.com> Tested-by:
-
Benjamin Berg authored
The function to add an interface may be called without a previous removal if the HW is being reconfigured. As such, only add the symlink if the hardware is not being reconfigured due to a HW_RESTART. Fixes: c36235ac ("wifi: iwlwifi: mvm: rework debugfs handling") Signed-off-by:
-
Johannes Berg authored
When a wiphy work is queued with timer, and then again without a delay, it's started immediately but *also* started again after the timer expires. This can lead, for example, to warnings in mac80211's offchannel code as reported by Jouni. Running the same work twice isn't expected, of course. Fix this by deleting the timer at this point, when queuing immediately due to delay=0. Cc: stable@vger.kernel.org Reported-by:
Jouni Malinen <j@w1.fi> Fixes: a3ee4dc8 ("wifi: cfg80211: add a work abstraction with special semantics") Link: https://msgid.link/20240125095108.2feb0eaaa446.I4617f3210ed0e7f252290d5970dac6a876aa595b@changeidSigned-off-by:
-
