| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Intentionally parsing single one element of RA report by breaking loop
causes a smatch warning:
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c:1678 rtl8188e_handle_ra_tx_report2() warn:
ignoring unreachable code.
With existing comments, it intends to process single one element for
station mode, but it will parse more elements in AP mode if it's
implemented. Implement program logic according to existing comment to avoid
smatch warning, and also be usable for both AP and stations modes.
Compile test only.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/r/202302142135.LCqUTVGY-lkp@intel.com/
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230216004654.4642-1-pkshih@realtek.com
|
|
By default the LED will blink when there is some activity.
This was tested with a TP-Link TL-WN725N.
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/34d62bf5-3595-0c77-2ca7-be78555f765d@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
|
|
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
|
|
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
|
