summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtl8xxxu
AgeCommit message (Collapse)AuthorFilesLines
2024-05-02wifi: rtl8xxxu: cleanup includesPing-Ke Shih10-117/+11
Remove unnecessary includes from driver. The first step is to add necessary includes to driver's header files to make them can be included individually. Then, driver's C files include driver's header files first, and check if still missed header files of kernel. The results show that most C files only include driver's header files. Only core.c needs to include additional linux/firmware.h. Also sort includes in alphabetic order. Compile tested only. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240429024711.30992-1-pkshih@realtek.com
2024-05-02wifi: rtl8xxxu: remove rtl8xxxu_ prefix from filenamesKalle Valo11-12/+12
The driver is already in a directory named rtl8xxxu, there's no need to duplicate that in the filename as well. Now file listing looks a lot more reasonable: 8188e.c 8192c.c 8192f.c 8723a.c core.c Makefile rtl8xxxu.h 8188f.c 8192e.c 8710b.c 8723b.c Kconfig regs.h No functional changes, compile tested only. Signed-off-by: Kalle Valo <kvalo@kernel.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240426141939.3881678-2-kvalo@kernel.org
2024-05-02wifi: rtl8xxxu: remove some unused includesKalle Valo9-36/+0
I noticed by random that rtl8xxxu includes linux/wireless.h even though it doesn't need it. While investigating a bit more I found even more unused include files: #include <linux/init.h> #include <linux/sched.h> #include <linux/ethtool.h> It looks like that the includes are just copied to every file without checking if the file really needs the include. So more includes could be removed but that would need more careful analysis per each file. No functional changes, compile tested only. Signed-off-by: Kalle Valo <kvalo@kernel.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240426141939.3881678-1-kvalo@kernel.org
2024-04-23wifi: rtl8xxxu: Add LED control code for RTL8723BUBitterblue Smith1-0/+23
Software control (on/off) and hardware control (automatic blinking) tested with EDUP EP-N8568. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/7df66d1f-87a1-4f44-9aac-ce75438abde3@gmail.com
2024-04-23wifi: rtl8xxxu: Add LED control code for RTL8192CU familyBitterblue Smith2-1/+22
Also, don't set bit 7 of LEDCFG2 for RTL8192CU. If bit 7 is set the LED never turns on. In this family only RTL8188CUS needs bit 7 of LEDCFG2 set. Software control (on/off) and hardware control (automatic blinking) tested with Netcore NW362 (RTL8192CU). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/4b5970cf-d28b-415a-b911-82cdb5e9ce99@gmail.com
2024-04-23wifi: rtl8xxxu: Add separate MAC init table for RTL8192CUBitterblue Smith4-28/+53
Until now RTL8192CU family was using the MAC init table from RTL8723AU, but these tables are not identical in the two vendor drivers. Import the correct table for RTL8192CU. Also move the existing MAC init table to rtl8xxxu_8723a.c, which is the only remaining user. Tested with the Netcore NW362 (RTL8192CU). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/a53ed8b9-27fc-4871-a20a-ad42c6d210d3@gmail.com
2024-04-22wifi: rtl8xxxu: enable MFP support with security flag of RX descriptorMartin Kaistra2-2/+14
In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frame is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Use the security flag in the RX descriptor for this purpose, like it is done in the rtw88 driver. Cc: stable@vger.kernel.org Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240418071813.1883174-3-martin.kaistra@linutronix.de
2024-04-22Revert "wifi: rtl8xxxu: enable MFP support"Martin Kaistra1-7/+2
This reverts commit 77f5924fc41c243e907c80ce2576902d3a9cb336. There is a more elegant solution to check for not decrypted frames, which is to check the security flag in the RX descriptor. Revert commit 77f5924fc41c ("wifi: rtl8xxxu: enable MFP support") in favor of this to be able to send it to stable. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240418071813.1883174-2-martin.kaistra@linutronix.de
2024-04-19wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AUBitterblue Smith1-15/+10
Don't subtract 1 from the power index. This was added in commit 2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts") for unknown reasons. The vendor drivers don't do this. Also correct the calculations of values written to REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver, these are used for TX power training. With these changes rtl8xxxu sets the TX power of RTL8192CU the same as the vendor driver. None of this appears to have any effect on my RTL8192CU device. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/6ae5945b-644e-45e4-a78f-4c7d9c987910@gmail.com
2024-03-20wifi: rtl8xxxu: enable MFP supportMartin Kaistra1-2/+7
In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frames is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240314164850.86432-1-martin.kaistra@linutronix.de
2024-02-28wifi: rtl8xxxu: fix mixed declarations in rtl8xxxu_set_aifs()Shiji Yang1-2/+2
Moving struct ieee80211_sta *sta variable definition to the front of the code to fix the ISO C90 forbids mixed declarations and code warning. Fixes: 43532c050f8e ("wifi: rtl8xxxu: support multiple interfaces in set_aifs()") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/TYAP286MB03157A408E0D69F2F6FBD88ABC552@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM
2024-02-21wifi: rtl8xxxu: check vif before using in rtl8xxxu_tx()Ping-Ke Shih1-2/+2
The 'vif' is from tx_info of SKB, and other codes check 'vif' before using, which raises smatch warnings: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5656 rtl8xxxu_tx() warn: variable dereferenced before check 'vif' (see line 5553) Compile tested only. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240216033923.34683-1-pkshih@realtek.com
2024-02-21wifi: mac80211: check beacon countdown is complete on per link basisAditya Kumar Singh1-1/+1
Currently, function to check if beacon countdown is complete uses deflink to fetch the beacon and check the counter. However, with MLO, there is a need to check the counter for the beacon in a particular link. Add support to use link_id in order to fetch the beacon from a particular link data. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240216144621.514385-2-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: add support to call csa_finish on a linkAditya Kumar Singh1-1/+1
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: simplify non-chanctx driversJohannes Berg1-0/+4
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-06wifi: rtl8xxxu: update rate mask per staMartin Kaistra2-38/+158
Until now, rtl8xxxu_watchdog_callback() only fetches RSSI and updates the rate mask in station mode. This means, in AP mode only the default rate mask is used. In order to have the rate mask reflect the actual connection quality, extend rtl8xxxu_watchdog_callback() to iterate over every sta. Like in the rtw88 driver, add a function to collect all currently present stas and then iterate over a list of copies to ensure no RCU lock problems for register access via USB. Remove the existing RCU lock in rtl8xxxu_refresh_rate_mask(). Since the currently used ieee80211_ave_rssi() is only for 'vif', add driver-level tracking of RSSI per sta. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240205093040.1941140-1-martin.kaistra@linutronix.de
2024-02-05wifi: rtl8xxxu: Add TP-Link TL-WN823N V2Chun Qiu1-1/+4
TP-Link TL-WN823N V2 (2357:0135) is based on rtl8192fu and has been tested to work with the rtl8xxxu driver. Signed-off-by: Chun Qiu <cqca@cock.lu> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240129053030.16369-1-cqca@cock.lu
2024-02-01wifi: rtl8xxxu: fix error messagesDan Carpenter1-2/+2
The first parameter of WARN_ONCE() is a condition so this code will end up printing the function name instead of the proper message. Fixes: 3ff7a05996f9 ("wifi: rtl8xxxu: support setting bssid register for multiple interfaces") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/7b144531-a8da-4725-8911-9b614a525a35@moroto.mountain
2024-01-19wifi: rtl8xxxu: add missing number of sec cam entries for all variantsMartin Kaistra7-0/+7
Commit b837f78fbffa ("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: b837f78fbffa ("wifi: rtl8xxxu: add hw crypto support for AP mode") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240116095001.399500-1-martin.kaistra@linutronix.de
2024-01-18wifi: rtl8xxxu: make instances of iface limit and combination to be static constPing-Ke Shih1-2/+2
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 <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240116080945.20172-2-pkshih@realtek.com
2024-01-18wifi: rtl8xxxu: convert EN_DESC_ID of TX descriptor to le32 typePing-Ke Shih1-1/+1
Fields of TX descriptor are little-endian order, so correct EN_DESC_ID field to le32 type. Fixes: b837f78fbffa ("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: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240116080945.20172-1-pkshih@realtek.com
2024-01-14wifi: rtl8xxxu: enable channel switch supportMartin Kaistra2-5/+16
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 <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240111163628.320697-3-martin.kaistra@linutronix.de
2024-01-14wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_workMartin Kaistra1-0/+1
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: e542e66b7c2e ("rtl8xxxu: add bluetooth co-existence support for single antenna") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240111163628.320697-2-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: Fix off by one initial RTS rateBitterblue Smith1-4/+3
rtl8xxxu_set_basic_rates() sets the wrong initial RTS rate. It sets the next higher rate than the one it should set, e.g. 36M instead of 24M. The while loop was supposed to find the index of the most significant bit which is 1, but it was copied incorrectly from the vendor driver. Use __fls() instead. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/761e6836-6cd6-4930-91b6-0446834655c5@gmail.com
2024-01-10wifi: rtl8xxxu: Fix LED control code of RTL8192FUBitterblue Smith2-9/+38
Some devices, like the Comfast CF-826F, use LED1, which already works. Others, like Asus USB-N13 C1, use LED0, which doesn't work correctly. Write the right values to the LED control registers to make LED0 work as well. This is unfortunately tested only with the Comfast CF-826F. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/7a2c3158-3a45-4466-b11e-fc09802b20e2@gmail.com
2024-01-10wifi: rtl8xxxu: declare concurrent mode support for 8188fMartin Kaistra3-0/+21
Everything is in place now for concurrent mode, we can tell the system that we support it. We will allow a maximum of 2 virtual interfaces, one of them can be in AP mode. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-22-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: make supporting AP mode only on port 0 transparentMartin Kaistra1-2/+89
When the driver is used for concurrent mode, both virtual interfaces can be set to station or AP mode, though only one can be in AP mode at the same time. In order to keep the code simple, use only hw port 0 for AP mode. When an interface is added in AP mode which would be assigned to port 1, use a switch_port function to transparently swap the mapping between virtual interface and hw port. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-21-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: add hw crypto support for AP modeMartin Kaistra3-10/+44
Add a custom function for allocating entries in the sec cam. This allows us to store multiple keys with the same keyidx. The maximum number of sec cam entries for 8188f is 16 according to the vendor driver. Add the number to rtl8xxxu_fileops, so that other chips which might support more entries, can set a different number there. Set the bssid as mac address for group keys instead of just using the ethernet broadcast address and use BIT(6) in the sec cam ctrl entry for differentiating them from pairwise keys like in the vendor driver. Add the TXDESC_EN_DESC_ID bit and the hw_key_idx to tx broadcast/multicast packets in AP mode. Finally, allow the usage of rtl8xxxu_set_key() for AP mode. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-20-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: remove obsolete priv->vifMartin Kaistra2-7/+0
Now that all uses of priv->vif have been converted to priv->vifs[] remove the old attribute. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-19-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: add macids for STA modeMartin Kaistra2-1/+18
Until now, the driver only assigned a dedicated macid for connections made in AP mode, in STA mode the return value of rtl8xxxu_get_macid() was simply 0. To differentiate between port 0 and 1, when both are in STA mode, allocate a second macid (with value 1) and set sta_info->macid according to the used port_num in rtl8xxxu_sta_add(). Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-18-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interface in start_ap()Martin Kaistra1-1/+2
Call set_bssid() with the correct port_num now. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-17-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interfaces in bss_info_changed()Martin Kaistra1-3/+5
Call set_linktype and set_bssid now with correct port_num. Call stop_tx_beacon only for port 0, as we don't support beacons on port 1. Explicit changes to BEACON will only happen for AP type interfaces, so we don't need an additional check there. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-16-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()Martin Kaistra2-22/+34
Add a custom struct to store in vif->drv_priv with a reference to port_num and fill it when a new interface is added. Choose a free port_num for the newly added interface. As we only want to support AP mode/sending beacons on port 0, only change the beacon settings if a new interface is actually assigned to port 0. Call set_linktype() and set_mac() with the appropriate port_num. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-15-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interfaces in watchdog_callback()Martin Kaistra1-8/+11
Check first whether priv->vifs[0] exists and is of type STATION, then go to priv->vifs[1]. Make sure to call refresh_rate_mask for both interfaces. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-14-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interfaces in configure_filter()Martin Kaistra1-2/+2
As we only want to support AP mode/sending beacons on port 0, change from priv->vif to priv->vifs[0] in the check for AP mode. Additionally, if we are in AP mode, don't filter RX beacon and probe response frames to still allow working STATION mode on the other interface. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-13-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interfaces in update_beacon_work_callback()Martin Kaistra1-1/+1
As we only want to support AP mode/sending beacons on port 0, it is enough to replace priv->vif with priv->vifs[0]. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-12-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support multiple interfaces in set_aifs()Martin Kaistra1-2/+8
In concurrent mode supported by this driver, both interfaces will use the same channel and same wireless mode. It is therefore possible to get the wireless mode by checking the first connected interface. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-11-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support setting bssid register for multiple interfacesMartin Kaistra1-4/+14
To prepare for concurrent mode, enhance rtl8xxxu_set_bssid() to write the BSSID of the respective interface to REG_BSSID or REG_BSSID1. Like done with rtl8xxxu_set_mac(), call rtl8xxxu_set_bssid() with port_num = 0, until the callers also support multiple interfaces. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-10-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: don't parse CFO, if both interfaces are connected in STA modeMartin Kaistra1-0/+10
If both interfaces are in STATION mode and both are connected to an AP, there might be conflicting CFO values for the two connections. Ignore the CFO information in this case. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-9-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: extend check for matching bssid to both interfacesMartin Kaistra1-8/+14
The driver will support two interfaces soon, which both can be in station mode, so extend the check, whether cfo information should be parsed, to cover both interfaces. For better code readability put the lines with priv->vifs[port_num] in a separate function. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-8-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: extend wifi connected check to both interfacesMartin Kaistra1-11/+9
There are multiple places in the code where the current connection status of wifi is checked. The driver will support two interfaces soon and either one of them (or both) could be connected. Convert all uses of (vif && vif->cfg.assoc) to a new helper function rtl8xxxu_is_assoc() which checks both interfaces. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-7-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support setting mac address register for both interfacesMartin Kaistra1-6/+14
To prepare for concurrent mode, enhance rtl8xxxu_set_mac() to write the mac address of the respective interface to REG_MACID or REG_MACID1. Remove the call to rtl8xxxu_set_mac() from the init function as we set it in rtl8xxxu_add_interface() later anyway. Until rtl8xxxu_add_interface() can handle both interfaces, call rtl8xxxu_set_mac() with port_num = 0. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-6-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: 8188e: convert usage of priv->vif to priv->vifs[0]Martin Kaistra1-1/+1
The driver currently does not support AP or concurrent mode for 8188e, so just use priv->vifs[0] instead of priv->vif for now. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-5-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: support setting linktype for both interfacesMartin Kaistra1-15/+22
To prepare for concurrent mode, enhance the set_linktype function to be able to set the linktype in the MSR register for both hardware ports. Until the users of set_linktype can handle multiple interfaces, use port_num = 0. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-4-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: prepare supporting two virtual interfacesMartin Kaistra2-3/+9
To prepare for concurrent mode, add an array ("vifs") to rtl8xxxu_priv to keep track of both interfaces. Keep the old priv->vif as long there are still users of it and let priv->vifs[0] point to the same location. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-3-martin.kaistra@linutronix.de
2024-01-10wifi: rtl8xxxu: remove assignment of priv->vif in rtl8xxxu_bss_info_changed()Martin Kaistra1-1/+0
priv->vif gets already set in rtl8xxxu_add_interface, there is no need to set it also in rtl8xxxu_bss_info_changed(). Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231222101442.626837-2-martin.kaistra@linutronix.de
2023-12-19wifi: rtl8xxxu: Add additional USB IDs for RTL8192EU devicesZenm Chen1-0/+12
Add additional USB IDs found in the vendor driver from https://github.com/Mange/rtl8192eu-linux-driver to support more RTL8192EU devices. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231217123017.1982-1-zenmchen@gmail.com
2023-09-18wifi: rtl8xxxu: Add a description about the device ID 0x7392:0xb722Zenm Chen1-0/+1
According to the driver provided by EDIMAX, the device ID 0x7392:0xb722 belongs to EDIMAX EW-7722UTn V3, so add a comment about this. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230912053614.10644-1-zenmchen@gmail.com
2023-09-04wifi: rtl8xxxu: mark TOTOLINK N150UA V5/N150UA-B as testedZenm Chen1-0/+1
TOTOLINK N150UA V5/N150UA-B (VID=0x0bda, PID=0x2005) works fine with the rtl8xxxu driver, so mark as tested. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230829074358.14795-1-zenmchen@gmail.com
2023-07-25wifi: rtl8xxxu: Enable AP mode for RTL8723BUBitterblue Smith1-0/+2
Theoretically this chip can handle 127 clients. Only compile tested but it should work as well as the RTL8188FU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/b2876c56-0ea7-c398-5c9b-635f9f894f2c@gmail.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-11 12:03:20 +0300