- Jan 23, 2024
-
-
Ping-Ke Shih authored
When we are going to up interface to make connection, turn on BB and RF hardware power by enable_bb_rf ops. Oppositely, using disable_bb_rf to turn them off. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240120003831.7014-3-pkshih@realtek.com
-
Ping-Ke Shih authored
WiFi 7 chips can operate in various MLO applications, such as 1 link (2SS) and 2 links (1SS + 1SS), and we should configure different PHY mode for each of them. For example, - MLO_2_PLUS_0_1RF is 1 link with 2SS rate, and enable one RF component. - MLO_1_PLUS_1_1RF is 2 links with 1SS rate for each, and enable one RF component that can support two paths. By default, we set the mode to legacy MLO_DBCC_NOT_SUPPORT (don't support MLO and DBCC yet), and later we will introduce logic to change the mode. Signed-off-by:
-
- Jan 20, 2024
-
-
Bitterblue Smith authored
Currently it takes almost 6 seconds to upload the firmware for RTL8192CU (and 11 seconds for RTL8192DU). That's because the firmware is uploaded one byte at a time. Also, after plugging the device, the firmware gets uploaded three times before a connection to the AP is established. Maybe this is fine for most users, but when testing changes to the driver it's really annoying to wait so long. Speed up the firmware upload by writing chunks of 64 bytes at a time. This way it takes about 110 ms for RTL8192CU (and about 210 ms for RTL8192DU). PCI devices could upload it in chunks of 4 bytes, but I don't have any to test and commit 89d32c90 ("rtlwifi: Download firmware as bytes rather than as dwords") decided otherwise anyway. Allocate memory for the firmware image with kmalloc instead of vzalloc because this memory is passed directly to usb_control_msg(), which can't take memory allocated by vmalloc. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by:
-
Martin Kaistra authored
Commit b837f78f ("wifi: rtl8xxxu: add hw crypto support for AP mode") introduced max_sec_cam_num as a member of rtl8xxxu_fileops. It was missed to set this number for all variants except 8188f, which caused rtl8xxxu_get_free_sec_cam() to always return 0 and therefore breaking encrypted traffic. Fix it by adding the numbers for all variants. The values are taken from the vendor drivers and rtlwifi. Link: https://lore.kernel.org/linux-wireless/20240111163603.2325-1-zenmchen@gmail.com/ Fixes: b837f78f ("wifi: rtl8xxxu: add hw crypto support for AP mode") Signed-off-by:
Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by:
-
Arend van Spriel authored
The firmware interface also defines events generated by firmware on the device. As the get/set primitives the events are likely to diverge between the vendors so this commit adds support for per-vendor handling. The number of events may differ so we let the vendor-specific code allocate the struct brcmf_fweh_info which contains array of event handlers. The existing event enumeration will be used by the higher layers and thus are common definitions. The vendor-specific code can provide a mapping table for converting the common definition to the vendor-specific firmware event definition and vice-versa. Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
When the brcmf_fwvid_attach() fails the driver instance is not added to the vendor list. Hence we should not try to delete it from that list when the brcmf_fwvid_detach() function is called in cleanup path. Cc: stable@vger.kernel.org # 6.2.x Fixes: d6a5c562 ("wifi: brcmfmac: add support for vendor-specific firmware api") Signed-off-by:
-
Hector Martin authored
People are getting spooked by brcmfmac errors on their boot console. There's no reason for these messages to be errors. Cc: stable@vger.kernel.org # 6.2.x Fixes: d6a5c562 ("wifi: brcmfmac: add support for vendor-specific firmware api") Signed-off-by:
Hector Martin <marcan@marcan.st> [arend.vanspriel@broadcom.com: remove attach/detach vendor callbacks] Signed-off-by:
-
Hector Martin authored
Using the WSEC command instead of sae_password seems to be the supported mechanism on newer firmware, and also how the brcmdhd driver does it. The existing firmware mechanism intended for (some) Cypress chips has been separated from the new firmware mechanism using the multi-vendor framework. Depending on the device it will select the appropriate firmware mechanism. This makes WPA3 work with iwd, or with wpa_supplicant pending a support patchset [2]. [1] https://rachelbythebay.com/w/2023/11/06/wpa3/ [2] http://lists.infradead.org/pipermail/hostap/2023-July/041653.html Signed-off-by:
Neal Gompa <neal@gompa.dev> [arend.vanspriel@broadcom.com: use multi-vendor framework] Signed-off-by:
-
Arend van Spriel authored
The feature_disable option in brcmf_feat_attach() is a debugging or workaround option to disable features that cause driver issues. Hence they should be done as last step after all feature detection mechanisms have been completed. Signed-off-by:
-
Arend van Spriel authored
Adding a .feat_attach() callback allowing per-vendor overrides of the driver feature flags. In this patch the callback is only provided by BCA vendor to disable SAE feature as it has not been confirmed yet. BCA chips generally do not have the in-driver supplicant (idsup) feature so they rely on NL80211_CMD_EXTERNAL_AUTH to trigger user-space authentication. Signed-off-by:
-
Arend van Spriel authored
With multi-vendor support the vendor-specific module may need to use the firmware interface functions so export them using the macro BRCMF_EXPORT_SYMBOL_GPL() which exports them to driver namespace. Signed-off-by:
-
- Jan 18, 2024
-
-
Zheng Wang authored
This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. Fixes: e756af5b ("brcmfmac: add e-scan support.") Signed-off-by:
Zheng Wang <zyytlz.wz@163.com> Cc: stable@vger.kernel.org [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free] Signed-off-by:
-
Dmitry Antipov authored
In 'rt2x00crypto_rx_insert_iv()', added alignment can't exceed 3 bytes and ICV size is either 4 or 8 bytes, so skb space adjustment may be simplified. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by:
-
Jinjie Ruan authored
debugfs_create_dir() returns ERR_PTR and never return NULL. As Russell suggested, this patch removes the error checking for debugfs_create_dir(). This is because the DebugFS kernel API is developed in a way that the caller can safely ignore the errors that occur during the creation of DebugFS nodes. The debugfs APIs have a IS_ERR() judge in start_creating() which can handle it gracefully. So these checks are unnecessary. Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Suggested-by:
Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by:
-
Ruan Jinjie authored
Use is_multicast_ether_addr() and is_unicast_ether_addr() to check the addresses. Signed-off-by:
-
Artem Chernyshev authored
wlc_phy_txpwr_srom_read_nphy() in wlc_phy_attach_nphy() can not return false, so it's impossible to get true value in this if-statement. Also change those functions return types to void since no one using it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
Artem Chernyshev <artem.chernyshev@red-soft.ru> Reviewed-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
-
Ping-Ke Shih authored
rtl8xxxu_limits and rtl8xxxu_combinations can be static const, so add modifiers as desire. Otherwise, Sparse reports warnings rtl8xxxu_core.c:7677:30: warning: symbol 'rtl8xxxu_limits' was not declared. Should it be static? rtl8xxxu_core.c:7682:36: warning: symbol 'rtl8xxxu_combinations' was not declared. Should it be static? Signed-off-by:
-
Ping-Ke Shih authored
Fields of TX descriptor are little-endian order, so correct EN_DESC_ID field to le32 type. Fixes: b837f78f ("wifi: rtl8xxxu: add hw crypto support for AP mode") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202401161318.YtXoCkjU-lkp@intel.com/ Cc: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by:
-
Ajay Singh authored
Adding then removing a second vif currently makes the first vif not working anymore. This is visible for example when we have a first interface connected to some access point: - create a wpa_supplicant.conf with some AP credentials - wpa_supplicant -Dnl80211 -c /etc/wpa_supplicant.conf -i wlan0 - dhclient wlan0 - iw phy phy0 interface add wlan1 type managed - iw dev wlan1 del wlan0 does not manage properly traffic anymore (eg: ping not working) This is due to vif mode being incorrectly reconfigured with some default values in del_virtual_intf, affecting by default first vif. Prevent first vif from being affected on second vif removal by removing vif mode change command in del_virtual_intf Fixes: 9bc061e8 ("staging: wilc1000: added support to dynamically add/remove interfaces") Signed-off-by:
Ajay Singh <ajay.kathat@microchip.com> Co-developed-by:
Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by:
-
Ajay Singh authored
Use the correct register configuration when the WILC chip is down so the successive interface up operation is successful. The modified registers values during chip down helps to avoid the "FW not responding" debug message which sometimes occurs because of temporary bus communication failure during the next start. Also, make sure on first communication with the chip that it is indeed woken up. Reported-by:
Michael Walle <mwalle@kernel.org> Closes: https://lore.kernel.org/linux-wireless/20221026085415.6jgwrhq4sunqaypm@0002.3ffe.de/ Signed-off-by:
-
Ajay Singh authored
Commit 09ed8bfc ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue. Fixes: 09ed8bfc ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") Signed-off-by:
-
Ajay Singh authored
During firmware initial configuration in wilc_init_fw_config, the special driver_handler 0 should be used instead of targeting a specific virtual interface (either 1 or 2) The issue does not seem to have real consequence (both virtual interfaces seems to answer correctly to a Add Block Ack request with the Immediate policy), but lets make everything homogeneous Signed-off-by:
-
Bitterblue Smith authored
Instead of reading bit 9 of RFPGA0_XA_HSSIPARAMETER2 every time a frame is received, just use rtlphy->cck_high_power, which is initialised in _rtl92d_phy_bb_config(). That bit never changes anyway. With this change _rtl92de_query_rxphystatus() can be shared with the upcoming USB driver. The USB driver can't read registers in this function because register reading can sleep. Compile tested only. Signed-off-by:
-
Ping-Ke Shih authored
WiFi 7 chips will support MLD, so there are more fields about that. But currently we don't support MLD yet, just define fields and bits by this patch ahead, and fill STA_TYPE only. Signed-off-by:
-
Ping-Ke Shih authored
The JOIN command is used to tell firmware an new station is joining, and create an entry for it. This patch is only to convert to set data via struct, and don't change logic at all. Signed-off-by:
-
Ping-Ke Shih authored
Reset DMAC table, so we get expected behavior instead of random values at early stage. Signed-off-by:
-
Ping-Ke Shih authored
Do reset on CMAC tables by mac_id, so we don't get random values when powering on. Therefore, add the same function for WiFi 7 chips. Signed-off-by:
-
Ping-Ke Shih authored
The CMAC table is used to define how hardware TX a certain packet, and we can specify TX AMPDU size, so hardware can prepare proper retry window buffer. Otherwise, it can't transmit with expected aggregation number. Since each TID could have different aggregation number, the smallest number is adopted to prevent over peer's receiving buffer. Signed-off-by:
-
Ping-Ke Shih authored
For WiFi 7 chips, we add H2C command with rich fields to support MLO, so add a chip_ops to generalize calling of update CMAC table. Signed-off-by:
-
Ping-Ke Shih authored
When a station get connected, fill hardware CMAC table via H2C command to tell hardware arguments related to transmit, such as the lowest rate, packet padding and so on. Signed-off-by:
-
Ping-Ke Shih authored
To have secure connection, set key information into security CAM including key index, entry index and valid map. This new introduced H2C command can support MLO, but currently not implement yet. Signed-off-by:
-
Ping-Ke Shih authored
According to IEEE Std. 802.11, it defines: Indicates whether the STA is capable of interpreting the Extended NSS BW Support subfield of the VHT Capabilities Information field. Some AP such as TP-LINK BE19000 would check it for bandwidth settings, so causes 80MHz rate when associating on 160 MHz bandwidth. Declare this capability to yield expected result. Signed-off-by:
-
Ping-Ke Shih authored
The coming WiFi 7 chip 8922A will support EHT, so declare EHT along with hardware capabilities. Signed-off-by:
-
Ping-Ke Shih authored
Basically, all chips can support 20/40/80MHz bandwidth, and 8952C can support 160MHz bandwidth, which is why we introduced support_bw160 before. The coming WiFi 7 chips will support 320MHz optionally, so change it to bit mask instead of adding another support_bw320. Signed-off-by:
-
Ping-Ke Shih authored
EHT capabilities are also stored in struct ieee80211_sband_iftype_data, so adjust allocation of iftype_data as common part named init_he_eht_cap(), and then init_eht_cap() can be added later. Don't change logic at all by this patch. Signed-off-by:
-
Dmitry Antipov authored
When 'sscanf()' is not needed to scan an input, prefer common 'kstrtoX_from_user()' over 'rtw_debugfs_copy_from_user()' with following 'kstrtoX()'. Minor adjustments, compile tested only. Signed-off-by:
-
- Jan 15, 2024
-
-
Martin Kaistra authored
The CSA countdown in the beacon frames, which are sent out by firmware, needs to get updated by the driver. To achieve this, convert update_beacon_work to delayed_work and schedule it with the beacon interval in case CSA is active and the countdown is not complete. Signed-off-by:
-
Martin Kaistra authored
The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop(). Fixes: e542e66b ("rtl8xxxu: add bluetooth co-existence support for single antenna") Signed-off-by:
-
- Jan 13, 2024
-
-
Bitterblue Smith authored
Currently rtl_usb performs register writes using the async usb_submit_urb() function. This appears to work fine for the RTL8192CU, but the RTL8192DU (soon to be supported by rtlwifi) has a problem: it transmits everything at the 1M rate in the 2.4 GHz band. (The 5 GHz band is still untested.) With this patch, rtl_usb performs the register writes using the synchronous usb_control_msg() function, and the RTL8192DU works normally. The RTL8192CU still works. The vendor drivers use the async writes in only one function, rtl8192du_trigger_gpio_0 / rtl8192cu_trigger_gpio_0, which probably doesn't even run in real life. They use sync writes everywhere else. Also, remove "sync" and "async" from the names of the members of struct rtl_io to avoid confusion: write{8,16,32}_async -> write{8,16,32} read{8,16,32}_sync -> read{8,16,32} Signed-off-by: -
Dmitry Antipov authored
Remove unreachable branches in 'rtl92ce_tx_fill_desc()', 'rtl92cu_tx_fill_desc()' and 'rtl8723e_tx_fill_desc()'. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
-
