| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
