summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
AgeCommit message (Collapse)AuthorFilesLines
2024-02-06wifi: rtl8xxxu: update rate mask per staMartin Kaistra1-1/+7
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-01-14wifi: rtl8xxxu: enable channel switch supportMartin Kaistra1-1/+1
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-10wifi: rtl8xxxu: declare concurrent mode support for 8188fMartin Kaistra1-0/+1
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: add hw crypto support for AP modeMartin Kaistra1-0/+5
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 Kaistra1-5/+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 Kaistra1-0/+1
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 interfaces in {add,remove}_interface()Martin Kaistra1-0/+4
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: prepare supporting two virtual interfacesMartin Kaistra1-0/+2
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
2023-06-07Merge wireless into wireless-nextJohannes Berg1-0/+1
There are a number of upcoming things in both the stack and drivers that would otherwise conflict, so merge wireless to wireless-next to be able to avoid those conflicts. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-15wifi: rtl8xxxu: Support new chip RTL8192FUBitterblue Smith1-0/+47
This is a newer chip, similar to the RTL8710BU in that it uses the same PHY status structs. Features: 2.4 GHz, b/g/n mode, 2T2R, 300 Mbps. It can allegedly have Bluetooth, but that's not implemented here. This chip can have many RFE (RF front end) types, of which types 1 and 5 are the only ones tested. Many of the other types need different initialisation tables. They can be added if someone wants them. The vendor driver v5.8.6.2_35538.20191028_COEX20190910-0d02 from https://github.com/BrightX/rtl8192fu was used as reference, with additional device IDs taken from https://github.com/kelebek333/rtl8192fu-dkms. The vendor driver also claims to support devices with ID 0bda:a725, but that is found in some bluetooth-only devices, so it's not supported here. 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://lore.kernel.org/r/7dcf9fb9-1c97-ac28-5286-2236e287a18c@gmail.com
2023-05-15wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR valueYun Lu1-0/+1
When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a probability of failure, which shows "authentication with ... timed out". Through debugging, it was found that the RCR register has been inexplicably modified to an incorrect value, resulting in the nic not being able to receive authenticated frames. To fix this problem, add regrcr in rtl8xxxu_priv struct, and store the RCR value every time the register is written, and use it the next time the register need to be modified. Signed-off-by: Yun Lu <luyun@kylinos.cn> Link: https://lore.kernel.org/all/20230427020512.1221062-1-luyun_611@163.com Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230512012055.2990472-1-luyun_611@163.com
2023-05-05wifi: rtl8xxxu: Set maximum number of supported stationsMartin Kaistra1-0/+1
Set maximum number of associated stations supported in AP mode. For 8188f, the maximum number of supported macids is 16, reserve one for broadcast/multicast frames. 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://lore.kernel.org/r/20230428150833.218605-19-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Declare AP mode support for 8188fMartin Kaistra1-0/+1
Everything is in place now for AP mode, we can tell the system that we support it. Put the feature behind a flag in priv->fops, because it is not (yet) implemented for all chips. 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://lore.kernel.org/r/20230428150833.218605-18-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Add parameter macid to update_rate_maskMartin Kaistra1-3/+4
The HW maintains a rate_mask for each connection, referenced by the macid. Add a parameter to update_rate_mask and add the macid to the h2c call in the gen2 implementation. Also extend refresh_rate_mask to get the macid from sta_info. 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://lore.kernel.org/r/20230428150833.218605-13-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Put the macid in txdescMartin Kaistra1-4/+4
Add a parameter macid to fill_txdesc(), implement setting it for the gen2 version. This is used to tell the HW who the recipient of the packet is, so that the appropriate data rate can be selected. 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://lore.kernel.org/r/20230428150833.218605-12-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Add sta_add() and sta_remove() callbacksMartin Kaistra1-0/+9
In AP mode, sta_add() gets called when a new STA gets associated to us. Call rtl8xxxu_refresh_rate_mask() to set a rate mask for the newly connected STA (referenced by the macid) and then send a media connnect report. Ignore the call to sta_add() in station mode. Reserve one macid for broadcast/multicast packets in init. 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://lore.kernel.org/r/20230428150833.218605-11-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Add parameter role to report_connectMartin Kaistra1-3/+6
This allows to tell the HW if a connection is made to a STA or an AP. Add the implementation for the gen2 version. 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://lore.kernel.org/r/20230428150833.218605-9-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Add beacon functionsMartin Kaistra1-0/+1
Add a workqueue to update the beacon contents asynchronously and implement downloading the beacon to the HW and starting beacon tx like the vendor driver. 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://lore.kernel.org/r/20230428150833.218605-4-martin.kaistra@linutronix.de
2023-05-05wifi: rtl8xxxu: Add start_ap() callbackMartin Kaistra1-0/+1
This gets called at the start of AP mode operation. Set bssid, beacon interval and send a connect report to the HW. 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://lore.kernel.org/r/20230428150833.218605-2-martin.kaistra@linutronix.de
2023-04-20wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear}Bitterblue Smith1-0/+12
Also add rtl8xxxu_write32_mask, rtl8xxxu_write_rfreg_mask. These helper functions make it easier to modify only parts of a register by eliminating the call to the register reading function and the bit manipulations. 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://lore.kernel.org/r/9430b841-1048-b27c-14ec-fca447dc32af@gmail.com
2023-04-14wifi: rtl8xxxu: Support devices with 5-6 out endpointsBitterblue Smith1-1/+1
Handle them the same way as the devices with 3-4 USB out endpoints. This is needed for the RTL8192FU. 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://lore.kernel.org/r/ef4bc66d-84f5-4021-efd7-1787d097519c@gmail.com
2023-04-14wifi: rtl8xxxu: Clean up some messy ifsBitterblue Smith1-0/+5
Add some new members to rtl8xxxu_fileops and use them instead of checking priv->rtl_chip. 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://lore.kernel.org/r/e24a5534-6e33-cfb9-0634-0caf4646513f@gmail.com
2023-03-20wifi: rtl8xxxu: Support new chip RTL8710BU aka RTL8188GUBitterblue Smith1-3/+310
This chip is found in cheap "free driver" USB adapters from Aliexpress. Initially they pretend to be a CD-ROM containing the driver for Windows. "Ejecting" switches the device to wifi mode. Features: 2.4 GHz, b/g/n mode, 1T1R, 150 Mbps. This chip is more unique than other Realtek chips: * The registers at addresses 0x0-0xff, which all the other chips use, can't be used here. New registers at 0x8000-0x80ff must be used instead. And it's not a simple matter of adding 0x8000: 0x2 (REG_SYS_FUNC) became 0x8004, 0x80 (REG_MCU_FW_DL) became 0x8090, etc. * Also there are a few new registers which must be accessed indirectly because their addresses don't fit in 16 bits. No other chips seem to have these. * The vendor driver compiles to 8188gu.ko, but the code calls the chip RTL8710B(U) pretty much everywhere, including messages visible to the user. Another difference compared to the other chips supported by rtl8xxxu is that it has a new PHY status struct, or three of them actually, from which we extract the RSSI, among other things. This is not unique, though, just new. The chips supported by rtw88 also use it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150 Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/4edbe29f-00b9-8eef-9789-20bed0b141e2@gmail.com
2023-02-13wifi: rtl8xxxu: Register the LED and make it blinkBitterblue Smith1-0/+8
If the chip can have an LED, register a struct led_classdev and enable hardware-controlled blinking. When the chip is not transmitting or receiving anything the LED is off. Otherwise the LED will blink faster or slower according to the throughput. The LED can be controlled from userspace by writing 0, 1, or 2 to /sys/class/leds/rtl8xxxu-usbX-Y/brightness: 0 - solid off. 1 - solid on. 2 - hardware-controlled blinking. In this patch none of the chips advertise having an LED. That will be added in the next patches. 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://lore.kernel.org/r/b8235bca-60c3-d0fe-a958-53c6dd3ba3f6@gmail.com
2023-01-16wifi: rtl8xxxu: Report the RSSI to the firmwareBitterblue Smith1-0/+23
Or in the case of RTL8188EU, report the RSSI to the rate control code. The rate control code for RTL8188EU is less likely to switch to a lower rate when the RSSI is high. The firmware-based rate control in the other chips probably works the same way. This affects all the chips, but it was only tested with RTL8188EU, RTL8188FU, and RTL8192EU. 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://lore.kernel.org/r/2aab4f3f-e914-4fe1-f29a-deac91774d05@gmail.com
2022-12-21wifi: rtl8xxxu: Add rate control code for RTL8188EUBitterblue Smith1-0/+39
Copied from the newer vendor driver, v5.2.2.4. 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://lore.kernel.org/r/5acc1e5d-62d6-3a6a-0f9e-cbc8b809b1d7@gmail.com
2022-12-21wifi: rtl8xxxu: Support new chip RTL8188EUJes Sorensen1-2/+65
This chip is found in cheap USB devices from TP-Link, D-Link, etc. Features: 2.4 GHz, b/g/n mode, 1T1R, 150 Mbps. Chip versions older than "I cut" need software rate control. That will be in the next commit. Until then MCS7 is used for all data frames. The "I cut" chips are not supported. They require different firmware and initialisation tables. Support can be added if someone has the hardware to test it. Co-developed-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Co-developed-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Co-developed-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> 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://lore.kernel.org/r/3aad60f6-23f9-81e8-c741-4bd51e99f423@gmail.com
2022-12-21wifi: rtl8xxxu: Define masks for cck_agc_rpt bitsBitterblue Smith1-0/+3
Define the constants CCK_AGC_RPT_LNA_IDX_MASK and CCK_AGC_RPT_VGA_IDX_MASK instead of using the same literals in four places. And get the bits from cck_agc_rpt using u8_get_bits(). It's a cosmetic change only. 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://lore.kernel.org/r/cfe79922-efdf-2ed0-7404-263915d19d82@gmail.com
2022-12-21wifi: rtl8xxxu: Make rtl8xxxu_load_firmware take const char*Bitterblue Smith1-1/+1
And pass const char* to it. 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://lore.kernel.org/r/361ceac1-cc73-605b-4b63-736bfce80833@gmail.com
2022-12-08wifi: rtl8xxxu: Add __packed to struct rtl8723bu_c2hBitterblue Smith1-1/+1
This struct is used to access a sequence of bytes received from the wifi chip. It must not have any padding bytes between the members. This doesn't change anything on my system, possibly because currently none of the members need more than byte alignment. Fixes: b2b43b7837ba ("rtl8xxxu: Initial functionality to handle C2H events for 8723bu") 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://lore.kernel.org/r/1a270918-da22-ff5f-29fc-7855f740c5ba@gmail.com
2022-11-16wifi: rtl8xxxu: Split up rtl8xxxu_identify_chipBitterblue Smith1-0/+5
Move the reusable parts into separate functions and create one identify_chip function for each chip type. This is preparation for supporting the RTL8710BU chip, which would need too many ugly changes to this function. Another reason to do this is to get rid of the long and scary if..else if..else block in the middle of the function. Everything should still work the same as before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/b268b5cf-071c-6292-0d90-0573e4fb2228@gmail.com
2022-11-16wifi: rtl8xxxu: Move burst init to a functionBitterblue Smith1-0/+2
No changes to functionality, just moving code to make rtl8xxxu_init_device look nicer. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/bef90bf8-716f-c92f-9403-12ef2bfefc15@gmail.com
2022-11-04wifi: rtl8xxxu: Fix the CCK RSSI calculationBitterblue Smith1-0/+3
The CCK RSSI calculation is incorrect for the RTL8723BU, RTL8192EU, and RTL8188FU. Add new functions for these chips with code copied from their vendor drivers. Use the old code only for the RTL8723AU and RTL8192CU. I didn't notice any difference in the reported signal strength with my RTL8188FU, but I didn't look very hard either. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/926c838f-4997-698b-4da9-44582e2af99a@gmail.com
2022-11-04wifi: rtl8xxxu: Add central frequency offset trackingBitterblue Smith1-3/+18
According to Realtek programmers, "to adjust oscillator to align central frequency of connected AP. Then, it can yield better performance." From commit fb8517f4fade ("rtw88: 8822c: add CFO tracking"). The RTL8192CU and a version of RTL8723AU apparently don't have the ability to adjust the oscillator, so this doesn't apply to them. This also doesn't apply to the wifi + bluetooth combo chips (RTL8723AU and RTL8723BU) because the CFO tracking should only be done when bluetooth is disabled, and determining that looked complicated. That leaves only the RTL8192EU and RTL8188FU chips. I tested this with the latter. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/80aba428-0aff-f4b2-dea5-35d1425982b6@gmail.com
2022-10-12wifi: rtl8xxxu: Make some arrays constBitterblue Smith1-4/+4
All the initialisation tables, plus rtl8xxxu_rfregs. Most of them were already static. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/9407f219-a7ba-676e-3d99-154d67b312d2@gmail.com
2022-10-04wifi: rtl8xxxu: Support new chip RTL8188FUBitterblue Smith1-0/+56
This chip is found in the cheapest USB adapters, e.g. 1.17 USD with VAT and shipping from China included. It's a gen 2 chip, similar to the RTL8723BU, but without Bluetooth. Features: 2.4 GHz, b/g/n mode, 1T1R, 150 Mbps. The vendor driver rtl8188fu version 4.3.23.6_20964.20170110 [0] was used as reference. The CD shipped with the device includes a newer driver, version 5.11.5-1-g12f7cde4b.20201102, but that one couldn't complete the WPA2 key exchange thing for whatever reason. [0] https://github.com/kelebek333/rtl8188fu Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/b14f299d-3248-98fe-eee1-ba50d2e76c74@gmail.com
2022-09-29wifi: rtl8xxxu: gen2: Enable 40 MHz channel widthBitterblue Smith1-3/+3
The module parameter ht40_2g was supposed to enable 40 MHz operation, but it didn't. Tell the firmware about the channel width when updating the rate mask. This makes it work with my gen 2 chip RTL8188FU. I'm not sure if anything needs to be done for the gen 1 chips, if 40 MHz channel width already works or not. They update the rate mask with a different structure which doesn't have a field for the channel width. Also set the channel width correctly for sta_statistics. Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function") Fixes: bd917b3d28c9 ("rtl8xxxu: fill up txrate info for gen1 chips") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/3a950997-7580-8a6b-97a0-e0a81a135456@gmail.com
2021-08-21rtl8xxxu: Fix the handling of TX A-MPDU aggregationChris Chiu1-0/+2
The TX A-MPDU aggregation is not handled in the driver since the ieee80211_start_tx_ba_session has never been started properly. Start and stop the TX BA session by tracking the TX aggregation status of each TID. Fix the ampdu_action and the tx descriptor accordingly with the given TID. Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210804151325.86600-1-chris.chiu@canonical.com
2021-06-19rtl8xxxu: Fix device info for RTL8192EU devicesPascal Terjan1-8/+3
Based on 2001:3319 and 2357:0109 which I used to test the fix and 0bda:818b and 2357:0108 for which I found efuse dumps online. == 2357:0109 == === Before === Vendor: Realtek Product: \x03802.11n NI Serial: === After === Vendor: Realtek Product: 802.11n NIC Serial not available. == 2001:3319 == === Before === Vendor: Realtek Product: Wireless N Serial: no USB Adap === After === Vendor: Realtek Product: Wireless N Nano USB Adapter Serial not available. Signed-off-by: Pascal Terjan <pterjan@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210424172959.1559890-1-pterjan@google.com
2021-04-17rtl8xxxu: Simplify locking of a skb list accessesChristophe JAILLET1-1/+0
The 'c2hcmd_lock' spinlock is only used to protect some __skb_queue_tail() and __skb_dequeue() calls. Use the lock provided in the skb itself and call skb_queue_tail() and skb_dequeue(). These functions already include the correct locking. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/8bcec6429615aeb498482dc7e1955ce09b456585.1617613700.git.christophe.jaillet@wanadoo.fr
2020-03-26rtl8xxxu: Feed current txrate information for mac80211Chris Chiu1-1/+11
The nl80211 commands such as 'iw link' can't get current txrate information from the driver. This commit fills in the tx rate information from the C2H RA report in the sta_statistics function. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200320063833.1058-3-chiu@endlessm.com
2020-03-26rtl8xxxu: add enumeration for channel bandwidthChris Chiu1-0/+9
There's a data field in H2C and C2H commands which is used to carry channel bandwidth information. Add enumeration to make it more descriptive in code. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200320063833.1058-2-chiu@endlessm.com
2020-03-23wireless: realtek: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200225002746.GA26789@embeddedor
2019-10-22rtl8xxxu: fix RTL8723BU connection failure issue after warm rebootChris Chiu1-0/+1
The RTL8723BU has problems connecting to AP after each warm reboot. Sometimes it returns no scan result, and in most cases, it fails the authentication for unknown reason. However, it works totally fine after cold reboot. Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE for cold reboot and warm reboot, the registers imply that the MAC is already powered and thus some procedures are skipped during driver initialization. Double checked the vendor driver, it reads the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any during initialization based on them. This commit only tells the RTL8723BU to do full initialization without checking MAC status. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-09rtl8xxxu: add bluetooth co-existence support for single antennaChris Chiu1-0/+37
The RTL8723BU suffers the wifi disconnection problem while bluetooth device connected. While wifi is doing tx/rx, the bluetooth will scan without results. This is due to the wifi and bluetooth share the same single antenna for RF communication and they need to have a mechanism to collaborate. BT information is provided via the packet sent from co-processor to host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h dose not really handle it. And there's no bluetooth coexistence mechanism to deal with it. This commit adds a workqueue to set the tdma configurations and coefficient table per the parsed bluetooth link status and given wifi connection state. The tdma/coef table comes from the vendor driver code of the RTL8192EU and RTL8723BU. However, this commit is only for single antenna scenario which RTL8192EU is default dual antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h is only for 8723b and 8192e so the mechanism is expected to work on both chips with single antenna. Note RTL8192EU dual antenna is not supported. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-09rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driverChris Chiu1-3/+52
We have 3 laptops which connect the wifi by the same RTL8723BU. The PCI VID/PID of the wifi chip is 10EC:B720 which is supported. They have the same problem with the in-kernel rtl8xxxu driver, the iperf (as a client to an ethernet-connected server) gets ~1Mbps. Nevertheless, the signal strength is reported as around -40dBm, which is quite good. From the wireshark capture, the tx rate for each data and qos data packet is only 1Mbps. Compare to the Realtek driver at https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12Mbps or better. The signal strength is reported similarly around -40dBm. That's why we want to improve. After reading the source code of the rtl8xxxu driver and Realtek's, the major difference is that Realtek's driver has a watchdog which will keep monitoring the signal quality and updating the rate mask just like the rtl8xxxu_gen2_update_rate_mask() does if signal quality changes. And this kind of watchdog also exists in rtlwifi driver of some specific chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have the same member function named dm_watchdog and will invoke the corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate mask. With this commit, the tx rate of each data and qos data packet will be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit to 23th bit means MCS4 to MCS7. It means that the firmware still picks the lowest rate from the rate mask and explains why the tx rate of data and qos data is always lowest 1Mbps because the default rate mask passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate, and MCS rate. However, with Realtek's driver, the tx rate observed from wireshark under the same condition is almost 65Mbps or 72Mbps, which indicating that rtl8xxxu could still be further improved. Signed-off-by: Chris Chiu <chiu@endlessm.com> Reviewed-by: Daniel Drake <drake@endlessm.com> Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 295Thomas Gleixner1-9/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of version 2 of the gnu general public license as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 64 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.894819585@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24rtl8xxxu: Fix trailing semicolonLuis de Bethencourt1-1/+1
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt <luisbg@kernel.org> Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-20rtl8xxxu: Update author/maintainer contact infoJes Sorensen1-1/+1
Update copyright year and email address. Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-25rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry countJes Sorensen1-12/+15
In order to obtain retry count for a given rate we need to pass the full struct ieee80211_tx_info to the function setting the rate in he TX descriptor. This uncovered a huge bug where the old code would use struct ieee80211_rate.flags to test for rate parameters, which is always zero, instead of the flags value from struct ieee80211_tx_rate. Time to find a brown paper bag :( Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-06 00:06:08 +0300