- 12 Dec, 2023 31 commits
-
-
Kunwu Chan authored
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Cc: Kunwu Chan <kunwu.chan@hotmail.com> Signed-off-by:
Kunwu Chan <chentao@kylinos.cn> Acked-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231211033019.238149-1-chentao@kylinos.cn
-
Chris Morgan authored
When the MAC address read from the efuse data is invalid, warn the user and use a random MAC address instead. On a device I am currently using (Anbernic RG-ARC) with a rtw8821cs the efuse appears to be incompletely/improperly programmed. The MAC address reads as ff:ff:ff:ff:ff:ff. When networkmanager attempts to initiate a connection (and I haven't hard-coded a MAC address or set it to random) it fails to establish a connection. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Dmitry Antipov authored
Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Tested-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Acked-by:
-
Arnd Bergmann authored
After -Wstringop-overflow got enabled, the rtw89 driver produced two odd warnings with gcc-13: drivers/net/wireless/realtek/rtw89/coex.c: In function 'rtw89_btc_ntfy_scan_start': drivers/net/wireless/realtek/rtw89/coex.c:5362:50: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 5362 | wl->dbcc_info.scan_band[phy_idx] = band; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ In file included from drivers/net/wireless/realtek/rtw89/coex.h:8, from drivers/net/wireless/realtek/rtw89/coex.c:5: drivers/net/wireless/realtek/rtw89/core.h:1441:12: note: at offset [64, 255] into destination object 'scan_band' of size 2 1441 | u8 scan_band[RTW89_PHY_MAX]; /* scan band in each phy */ | ^~~~~~~~~ drivers/net/wireless/realtek/rtw89/coex.c: In function 'rtw89_btc_ntfy_switch_band': drivers/net/wireless/realtek/rtw89/coex.c:5406:50: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 5406 | wl->dbcc_info.scan_band[phy_idx] = band; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/net/wireless/realtek/rtw89/core.h:1441:12: note: at offset [64, 255] into destination object 'scan_band' of size 2 1441 | u8 scan_band[RTW89_PHY_MAX]; /* scan band in each phy */ | ^~~~~~~~~ I don't know what happened here, but adding an explicit range check shuts up the output. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
https://github.com/nbd168/wirelessKalle Valo authored
mt76 patches for 6.8 * fixes * nvmem eeprom improvements * mt7996 eht improvements * mt7996 wed support * mt7996 36-bit DMA support
-
Dmitry Antipov authored
The WARN_ON() in subject was actually seen only once, with 5.10.200 under syzkaller. It looks like a weird artifact of (ab?)using the syzkaller itself [1], and hopefully may be safely removed. [1] https://lore.kernel.org/linux-wireless/1bd8f266-dee0-4d4e-9b50-e22546b55763@yandex.ru/T/#uSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The ESS capability bit is reserved in frames transmitted by the client, so we shouldn't set it. Since we've set it for decades, keep that old behaviour unless we're connection to a new EHT AP. Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231211085121.65005aba900b.I3d00c8741400572a89a7508b5ae612c968874ad7@changeidSigned-off-by:
-
Benjamin Berg authored
When doing a channel switch, cfg80211_update_known_bss may be called with a BSS where both proberesp_ies and beacon_ies is set. If that happens, both need to be consumed. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Benjamin Berg authored
The specification says that this information should not be explicitly included in the per-STA profile. However, we need this information readily available in the BSS for userspace and also internally when associating. As such, append the appropriate element before adding/updating the BSS. Signed-off-by:
-
Andrei Otcheretianski authored
ENOTSUPP isn't a standard error code, don't use it. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by:
-
Andrei Otcheretianski authored
ENOTSUP isn't a standard error code. EOPNOTSUPP should be used instead. Signed-off-by:
-
Johannes Berg authored
There may be cases where puncturing isn't possible, and a connection needs to be downgraded. Add a hardware flag to support this. This is likely temporary: it seems we will need to move puncturing to the chandef/channel context. Signed-off-by:
-
Ilan Peer authored
Add support for setting the TID to link mapping for a non-AP MLD station. This is useful in cases user space needs to restrict the possible set of active links, e.g., since it got a BSS Transition Management request forcing to use only a subset of the valid links etc. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Reviewed-by:
-
Johannes Berg authored
With the locking rework, more functions need to be called with the wiphy mutex held. Document that, and for that use the "Context" description that shows up more nicely in the generated documentation. Signed-off-by:
-
Johannes Berg authored
Sometimes there may be reasons for which a BSS that's actually found in scan cannot be used to connect to, for example a nonprimary link of an NSTR mobile AP MLD cannot be used for normal direct connections to it. Not indicating these to userspace as we do now of course avoids being able to connect to them, but it's better if they're shown to userspace and it can make an appropriate decision, without e.g. doing an additional ML probe. Thus add an indication of what a BSS can be used for, currently "normal" and "MLD link", including a reason bitmap for it being not usable. The latter can be extended later for certain BSSes if there are other reasons they cannot be used. Signed-off-by:
-
Emmanuel Grumbach authored
Newest firmware has completely offloaded this logic and this command will be deprecated soon. Based on a capability bit advertised by the firmware, skip this command. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
There's only one user of this code, which is STA unblock during sleep for uAPSD on really old devices. Instead of having this all through the API with calls up and down, just implemented a special-case CMD_BLOCK_TXQS flag for this, it's only needed in the old gen1 transport. While at it, fix a complain that lockdep would have, as we lock the cmd queue and then the TXQs in the reclaim by using spin_lock_nested(). We no longer need to disable BHs in iwl_trans_pcie_block_txq_ptrs() since it's called with them disabled already. Signed-off-by:
-
Johannes Berg authored
This causes fortify warnings when compiled against recent kernels with recent compilers, and generally is not supported in the kernel anymore. Signed-off-by:
-
Johannes Berg authored
This never returns an error and the return value is never checked anyway, so it can just be void. Signed-off-by:
-
Johannes Berg authored
Signed-off-by:
-
Johannes Berg authored
We shouldn't access the device if we don't hold a reference, and if - after locking - we see that it has no bus, we also can't do anything, in fact, pci_stop_and_remove_bus_device() will be a no-op. Signed-off-by:
-
Emmanuel Grumbach authored
This can be used by the user space when it wants to clear the data we collected so far for privacy reasons. Signed-off-by:
-
Johannes Berg authored
When there's not going to be any data in the data event, we don't need to add it at all (unlike the TX version, it has no data at all.) Also combine the tracing into a separate inline so we only call iwl_rx_trace_len() once, which also simplifies things, and lets us have a single place to later add other checks. Signed-off-by:
-
Miri Korenblit authored
EHT CQI is one of the EHT PHY capabilities. We don't support EHT CQI. The non-triggered CQI feedback bit was unset in a previous patch, but the triggered CQI feedback bit wasn't. Unset it. Fixes: 0e21ec6e ("wifi: iwlwifi: nvm: Update EHT capabilities for GL device") Signed-off-by:
-
Ilan Peer authored
For an MLO connection, the BSSID of the link used during the scanning should be used (and not the one from the default link). Signed-off-by:
-
Ilan Peer authored
If a valid link ID was provided in the scan request use it instead of picking one of the active links. Signed-off-by:
-
Vinayak Yadawad authored
Current handling of del pmksa with SSID is limited to FILS security. In the current change the del pmksa support is extended to SAE/OWE security offloads as well. For OWE/SAE offloads, the PMK is generated and cached at driver/FW, so user app needs the capability to request cache deletion based on SSID for drivers supporting SAE/OWE offload. Signed-off-by:
Vinayak Yadawad <vinayak.yadawad@broadcom.com> Link: https://msgid.link/ecdae726459e0944c377a6a6f6cb2c34d2e057d0.1701262123.git.vinayak.yadawad@broadcom.com [drop whitespace-damaged rdev_ops pointer completely, enabling tracing] Signed-off-by:
-
Dmitry Antipov authored
Prefer native jiffies-wide 'unsigned long' for the 'last_active' field of 'struct airtime_info' and introduce 'ieee80211_sta_keep_active()' for airtime check in 'ieee80211_txq_keep_active()' and 'ieee80211_sta_register_airtime()'. Signed-off-by:
Toke Høiland-Jørgensen <toke@toke.dk> Link: https://msgid.link/20231206060935.612241-1-dmantipov@yandex.ruSigned-off-by:
-
Evan Quan authored
To support the WBRF mechanism, Wifi adapters utilized in the system must register the frequencies in use (or unregister those frequencies no longer used) via the dedicated calls. So that, other drivers responding to the frequencies can take proper actions to mitigate possible interference. Co-developed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Evan Quan <quanliangl@hotmail.com> Signed-off-by:
Ma Jun <Jun.Ma2@amd.com> Link: https://msgid.link/20231211100630.2170152-5-Jun.Ma2@amd.comSigned-off-by:
-
Evan Quan authored
The newly added WBRF feature needs this interface for channel width calculation. Signed-off-by:
-
Johannes Berg authored
Merge the platform drivers tag for WRBF. Hans says: Immutable branch between pdx86 amd wbrf branch and wifi / amdgpu due for the v6.8 merge window platform-drivers-x86-amd-wbrf-v6.8-1: v6.7-rc1 + AMD WBRF support for merging into the wifi subsys and amdgpu driver for 6.8. Merge it so we can apply the wifi tie-in for this feature. Signed-off-by:
-
- 11 Dec, 2023 7 commits
-
-
Ming Yen Hsieh authored
To avoid using incorrect 6g power settings after disconnection, it should to update back to the default state when disconnected. Fixes: 51ba0e3a ("wifi: mt76: mt7921: add 6GHz power type support for clc") Signed-off-by:
Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Ming Yen Hsieh authored
When enter suspend/resume while in a connected state, the upper layer will trigger disconnection before entering suspend, and at the same time, it will trigger regd_notifier() and update CLC, causing the CLC event to not be received due to suspend, resulting in a command timeout. Therefore, the update of CLC is postponed until resume, to ensure data consistency and avoid the occurrence of command timeout. Fixes: 4fc8df50 ("wifi: mt76: mt7921: get regulatory information from the clc event") Signed-off-by:
-
Ming Yen Hsieh authored
Due to the increase in the number of power tables for 6Ghz on CLC, the variable nr_country is no longer sufficient to represent the total quantity. Therefore, we have switched to calculating the length of clc buf to obtain the correct power table. Additionally, the version number has been incremented to 1. Fixes: 23bdc5d8 ("wifi: mt76: mt7921: introduce Country Location Control support") Signed-off-by:
-
Sean Wang authored
We actually don't need the reserve the 512 entries for the MCU firmware download Rx queue because the queue was only used in the firmware download phase to save the most of space and the reduction can significantly help with reducing latency we spent by ~20% further in resetting the Rx queue as the device was waking up from deep sleep mode. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sujuan Chen authored
Introduce the capability to run mt7996 driver on boards with more than 4GB of memory. Co-developed-by:
Rex Lu <rex.lu@mediatek.com> Signed-off-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Ma Jun authored
Due to electrical and mechanical constraints in certain platform designs there may be likely interference of relatively high-powered harmonics of the (G-)DDR memory clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate this, AMD has introduced a mechanism that devices can use to notify active use of particular frequencies so that other devices can make relative internal adjustments as necessary to avoid this resonance. Co-developed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Ma Jun authored
Add documentation about AMD's Wifi band RFI mitigation (WBRF) mechanism explaining the theory and how it is used. Signed-off-by:
-
- 07 Dec, 2023 2 commits
-
-
Wang Zhao authored
The ieee80211_queue_work function queues work into the mac80211 local->workqueue, which is widely used for mac80211 internal work processes. In the mt76 driver, both the mt76-sido-status and mt76-sdio-net threads enqueue workers to the workqueue with this function. However, in some cases, when two workers are enqueued to the workqueue almost simultaneously, the second worker may not be scheduled immediately and may get stuck for a while. This can cause timing issues. To avoid these timing conflicts caused by worker scheduling, replace the worker with an independent thread. Fixes: 48fab5bb ("mt76: mt7921: introduce mt7921s support") Signed-off-by:
Wang Zhao <wang.zhao@mediatek.com> Signed-off-by:
Deren Wu <deren.wu@mediatek.com> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert the three mt76 drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
-
