#
1cd165ad |
|
22-Dec-2023 |
Martin Kaistra <martin.kaistra@linutronix.de> |
wifi: rtl8xxxu: declare concurrent mode support for 8188f 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
|
#
b837f78f |
|
22-Dec-2023 |
Martin Kaistra <martin.kaistra@linutronix.de> |
wifi: rtl8xxxu: add hw crypto support for AP mode 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
|
#
103d6e9d |
|
13-May-2023 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Rename some registers Give proper names: RF6052_REG_UNKNOWN_56 -> RF6052_REG_PAD_TXG RF6052_REG_UNKNOWN_DF -> RF6052_REG_GAIN_CCA And fix typos: REG_OFDM0_AGCR_SSI_TABLE -> REG_OFDM0_AGC_RSSI_TABLE REG_BB_ACCEESS_CTRL -> REG_BB_ACCESS_CTRL 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/40157253-76bd-8b23-06e0-3365139b5395@gmail.com
|
#
c98411dc |
|
13-May-2023 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Support new chip RTL8192FU 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
|
#
b9a07c44 |
|
28-Apr-2023 |
Martin Kaistra <martin.kaistra@linutronix.de> |
wifi: rtl8xxxu: Set maximum number of supported stations 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
|
#
b468481c |
|
28-Apr-2023 |
Martin Kaistra <martin.kaistra@linutronix.de> |
wifi: rtl8xxxu: Declare AP mode support for 8188f 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
|
#
af8678e6 |
|
17-Apr-2023 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Don't print the vendor/product/serial Most devices have a vendor name, product name, and serial number in the efuse, but it's pretty useless. It duplicates the information already printed by the USB subsystem: usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial not available. usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 002E2DC0041F -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00E04C0001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial: 00E04C0001 Also, that data is not interpreted correctly in all cases: usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1.1.2: Product: 802.11n NIC usb 3-1.1.2: Manufacturer: Realtek usb 3-1.1.2: Vendor: Realtek usb 3-1.1.2: Product: \x03802.11n NI usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231 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/a2a7d9df-0529-7890-3522-48dce613753f@gmail.com
|
#
a5be45ea |
|
10-Apr-2023 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Clean up some messy ifs 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
|
#
70664495 |
|
13-Mar-2023 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Support new chip RTL8710BU aka RTL8188GU 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
|
#
3922dc9f |
|
08-Jan-2023 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Report the RSSI to the firmware 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
|
#
3dfb8e84 |
|
17-Dec-2022 |
Jes Sorensen <Jes.Sorensen@gmail.com> |
wifi: rtl8xxxu: Support new chip RTL8188EU 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
|
#
b75289e8 |
|
17-Dec-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Define masks for cck_agc_rpt bits 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
|
#
d7a3705c |
|
17-Dec-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Make rtl8xxxu_load_firmware take const char* 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
|
#
4f198e72 |
|
17-Dec-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Deduplicate the efuse dumping code Every chip family except RTL8723AU has a copy of the efuse dumping code. Remove this and dump the efuse from a single place using a new function rtl8xxxu_dump_efuse(). Also, use print_hex_dump() to print the efuse instead of a loop and dev_info(). It shows the ASCII interpretation of the bytes, which is nice. 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/2aa5200a-ee42-e064-16a1-672bed5708c6@gmail.com
|
#
9e32b4a7 |
|
08-Dec-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Fix assignment to bit field priv->pi_enabled Just because priv->pi_enabled is only one bit doesn't mean it works like a bool. The value assigned to it loses all bits except bit 0, so only assign 0 or 1 to it. This affects the RTL8188FU, but fixing the assignment didn't make a difference for my device. Fixes: c888183b21f3 ("wifi: rtl8xxxu: Support new chip RTL8188FU") 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/4368d585-11ec-d3c7-ec12-7f0afdcedfda@gmail.com
|
#
60d18ddb |
|
10-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Use u32_get_bits in *_identify_chip It simplifies the code a bit. Suggested-by: Ping-Ke Shih <pkshih@realtek.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/68f94284-3728-7b75-2b7b-64fae8af6bc5@gmail.com
|
#
9b00565a |
|
10-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Use strscpy instead of sprintf Fill priv->chip_name and priv->chip_vendor with strscpy instead of sprintf. This is just to prevent future bugs in case the name of a chip/vendor becomes longer than the size of chip_name/chip_vendor. Suggested-by: Ping-Ke Shih <pkshih@realtek.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/5fc9cc0e-eecb-8428-aeb1-f745791c0f16@gmail.com
|
#
e948023d |
|
05-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Rename rtl8xxxu_8188f_channel_to_group This name is an anomaly. Change it to rtl8188f_channel_to_group to follow the same pattern as the other functions. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Acked-by: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/ba8e3ea2-74f5-e1db-296e-4ae5f03084dc@gmail.com
|
#
14566bbf |
|
05-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Split up rtl8xxxu_identify_chip 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
|
#
bcfcb712 |
|
05-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Move burst init to a function 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
|
#
2ad2a813 |
|
01-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Fix the CCK RSSI calculation 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
|
#
57b328bc |
|
01-Nov-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Add central frequency offset tracking 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
|
#
80e5acb6 |
|
20-Oct-2022 |
Colin Ian King <colin.i.king@gmail.com> |
wifi: rtl8xxxu: Fix reads of uninitialized variables hw_ctrl_s1, sw_ctrl_s1 Variables hw_ctrl_s1 and sw_ctrl_s1 are not being initialized and potentially can contain any garbage value. Currently there is an if statement that sets one or the other of these variables, followed by an if statement that checks if any of these variables have been set to a non-zero value. In the case where they may contain uninitialized non-zero values, the latter if statement may be taken as true when it was not expected to. Fix this by ensuring hw_ctrl_s1 and sw_ctrl_s1 are initialized. Cleans up clang warning: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c:432:7: warning: variable 'hw_ctrl_s1' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (hw_ctrl) { ^~~~~~~ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c:440:7: note: uninitialized use occurs here if (hw_ctrl_s1 || sw_ctrl_s1) { ^~~~~~~~~~ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c:432:3: note: remove the 'if' if its condition is always true if (hw_ctrl) { ^~~~~~~~~~~~~ Fixes: c888183b21f3 ("wifi: rtl8xxxu: Support new chip RTL8188FU") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221020135709.1549086-1-colin.i.king@gmail.com
|
#
79cac25e |
|
08-Oct-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Make some arrays const 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
|
#
c888183b |
|
28-Sep-2022 |
Bitterblue Smith <rtl8821cerfe2@gmail.com> |
wifi: rtl8xxxu: Support new chip RTL8188FU 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
|