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
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
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
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
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
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
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>
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>
This was the last user of the old
rtl8xxxu_old_init_queue_reserved_page() which can now be removed.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This enables aggregation on rtl8192cu and derivative parts. This uses
the same parameters as for rtl8723au.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Use %*ph specifier to dump small buffers in hex format instead of doing this
byte-by-byte.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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>
This moves the code for rtl8188c, rtl8188r, and rtl8192c into it's own
file. This is purely a code moving exercise, there is no change to the
code itself.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
