summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
AgeCommit message (Collapse)Author
2024-01-19wifi: rtl8xxxu: add missing number of sec cam entries for all variantsMartin Kaistra
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
2023-04-20wifi: rtl8xxxu: Don't print the vendor/product/serialBitterblue Smith
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
2023-03-20wifi: rtl8xxxu: Support new chip RTL8710BU aka RTL8188GUBitterblue Smith
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: Add LED control code for RTL8723AUBitterblue Smith
By default the LED will blink when there is some activity. This is only compile tested. 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/73323811-aa58-a1be-7867-a5d45b7ae3d6@gmail.com
2023-01-16wifi: rtl8xxxu: Report the RSSI to the firmwareBitterblue Smith
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: Make rtl8xxxu_load_firmware take const char*Bitterblue Smith
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-11-16wifi: rtl8xxxu: Use u32_get_bits in *_identify_chipBitterblue Smith
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
2022-11-16wifi: rtl8xxxu: Use strscpy instead of sprintfBitterblue Smith
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
2022-11-16wifi: rtl8xxxu: Split up rtl8xxxu_identify_chipBitterblue Smith
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-04wifi: rtl8xxxu: Fix the CCK RSSI calculationBitterblue Smith
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 Smith
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 Smith
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 Smith
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
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 295Thomas Gleixner
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>
2017-01-20rtl8xxxu: Update author/maintainer contact infoJes Sorensen
Update copyright year and email address. Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-09-03rtl8xxxu: Split filling of TX descriptors into separate functionsJes Sorensen
Split the filling of TX descriptors into a generic portion used on all devices, and format specific helper functions provided in the fops structure. This also cleaned up some mess, even if non harmful, in the handling of txdesc40 descriptors, where the code randomly would switch between the pointer to tx_desc and tx_desc40. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-09-03rtl8xxxu: Switch 8723a to use new rtl8xxxu_init_queue_reserved_page() routineJes Sorensen
This changes the pub-queue value written to REQ_RQPN, however the old code used a hard coded minimum value assuming there would always be an active lo-queue, even when no USB EP was found for it. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-07-08rtl8xxxu: Enable aggregation for rtl8723auJes Sorensen
Implement rtl8xxxu_gen1_init_aggregation(). Aggregation should be the same for all gen1 parts. We may want to allow for tuning parameters in the fileopes struct. For now this is based allocating 16KB RX buffers, leaving 16000 bytes for actual packets, and the rest for the skb overhead. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-05-03rtl8xxxu: Remove the now obsolete mbox_ext_reg info from rtl8xxxu_fileopsJes Sorensen
With two different h2c_cmd() functions, mbox_ext_reg and mbox_ext_width are no longer needed. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-05-03rtl8xxxu: Rename rtl8723a_disabled_to_emu() to rtl8xxxu_disabled_to_emu()Jes Sorensen
This function is generic to most of the chips, so change the name to reflect this. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-05-03rtl8xxxu: move rtl8723a related code into rtl8xxxu_8723a.cJes Sorensen
This moves the rtl8723a code into it's own file. This is purely a code moving exercise, no code changes. This device specific file is a lot smaller since the gen1 chips (8723a, 8188c, 8188r, 8192c) share a lot more common code than the gen2 chips. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2024-07-04 11:17:40 +0000