[ Upstream commit 76c16af2cb10282274596e21add2c9f0b95c941b ]
The gen 2 chips RTL8192EU and RTL8188FU periodically send the driver
reports about the TX rate, and the driver passes these reports to
sta_statistics. The reports from RTL8192EU may or may not include the
channel width. The reports from RTL8188FU do not include it.
Only access the c2h->ra_report.bw field if the report (skb) is big
enough.
The other problem fixed here is that the code was actually never
changing the channel width initially reported by
rtl8xxxu_bss_info_changed because the value of RATE_INFO_BW_20 is 0.
Fixes: 0985d3a410 ("rtl8xxxu: Feed current txrate information for mac80211")
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/5b41f1ae-72e7-6b7a-2459-b736399a1c40@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit dd469a754afdb782ba3033cee102147493dc39f4 ]
This struct is used to access a sequence of bytes received from the
wifi chip. It must not have any padding bytes between the members.
This doesn't change anything on my system, possibly because currently
none of the members need more than byte alignment.
Fixes: b2b43b7837 ("rtl8xxxu: Initial functionality to handle C2H events for 8723bu")
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/1a270918-da22-ff5f-29fc-7855f740c5ba@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6f103aeb5e985ac08f3a4a049a2c17294f40cff9 ]
The wifi + bluetooth combo chips (RTL8723AU and RTL8723BU) read the
chip vendor from the wrong register because the val32 variable gets
overwritten. Add one more variable to avoid this.
This had no real effect on RTL8723BU. It may have had an effect on
RTL8723AU.
Fixes: 26f1fad29a ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/24af8024-2f07-552b-93d8-38823d8e3cb0@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5574d3290449916397f3092dcd2bac92415498e1 ]
ieee80211_tx_queue_params.aifs is not supposed to be written directly
to the REG_EDCA_*_PARAM registers. Instead process it like the vendor
drivers do. It's kinda hacky but it works.
This change boosts the download speed and makes it more stable.
Tested with RTL8188FU but all the other supported chips should also
benefit.
Fixes: 26f1fad29a ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Jes Sorensen <jes@trained-monkey.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/038cc03f-3567-77ba-a7bd-c4930e3b2fad@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d5350756c03cdf18696295c6b11d7acc4dbf825c ]
It looks like a leftover from copying rtl8xxxu_update_rate_mask,
which is used with the gen1 chips.
It wasn't causing any problems for my RTL8188FU test device, but it's
clearly a mistake, so remove it.
Fixes: f653e69009 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/d5544fe8-9798-28f1-54bd-6839a1974b10@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e963a19c64ac0d2f8785d36a27391abd91ac77aa ]
Found by comparing with the vendor driver. Currently this affects
only the RTL8192EU, which is the only gen2 chip with 2 TX paths
supported by this driver. It's unclear what kind of effect the
mistake had in practice, since I don't have any RTL8192EU devices
to test it.
Fixes: e1547c535e ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/30a59f3a-cfa9-8379-7af0-78a8f4c77cfd@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit edd5747aa12ed61a5ecbfa58d3908623fddbf1e8 ]
rtl8xxxu_queue_select() selects the wrong TX queues because it's
reading memory from the wrong address. It expects to find ieee80211_hdr
at skb->data, but that's not the case after skb_push(). Move the call
to rtl8xxxu_queue_select() before the call to skb_push().
Fixes: 26f1fad29a ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/7fa4819a-4f20-b2af-b7a6-8ee01ac49295@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 620d5eaeb9059636864bda83ca1c68c20ede34a5 ]
There some bounds checking to ensure that "map_addr" is not out of
bounds before the start of the loop. But the checking needs to be
done as we iterate through the loop because "map_addr" gets larger as
we iterate.
Fixes: 26f1fad29a ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/Yv8eGLdBslLAk3Ct@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 93fbc1ebd978cf408ef5765e9c1630fce9a8621b ]
Since IQK could spend time, we make a cache of IQK result matrix that looks
like iqk_matrix[channel_idx].val[x][y], and we can reload the matrix if we
have made a cache. To determine a cache is made, we check
iqk_matrix[channel_idx].val[0][0].
The initial commit 7274a8c229 ("rtlwifi: rtl8192de: Merge phy routines")
make a mistake that checks incorrect iqk_matrix[channel_idx].val[0] that
is always true, and this mistake is found by commit ee3db469dd31
("wifi: rtlwifi: remove always-true condition pointed out by GCC 12"), so
I recall the vendor driver to find fix and apply the correctness.
Fixes: 7274a8c229 ("rtlwifi: rtl8192de: Merge phy routines")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220801113345.42016-1-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ee3db469dd317e82f57b13aa3bc61be5cb60c2b4 upstream.
The .value is a two-dim array, not a pointer.
struct iqk_matrix_regs {
bool iqk_done;
long value[1][IQK_MATRIX_REG_NUM];
};
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b88d28146c30a8e14f0f012d56ebf19b68a348f4 ]
If the copy_from_user() fails or the user gives invalid date then the
correct thing to do is to return a negative error code. (Currently it
returns success).
I made a copy additional related cleanups:
1) There is no need to check "buffer" for NULL. That's handled by
copy_from_user().
2) The "h2c_len" variable cannot be negative because it is unsigned
and because sscanf() does not return negative error codes.
Fixes: 610247f46f ("rtlwifi: Improve debugging by using debugfs")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/YoOLnDkHgVltyXK7@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 746285cf81dc19502ab238249d75f5990bd2d231 upstream.
Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.
Ignore the skb priority for those cards, they only have one tx queue. Pierre
Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:
https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html
He also confirmed that this patch fixes the issue. In summary this happened:
After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a
"divide error: 0000" when connecting to an AP. Control port tx now tries to
use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in
2.10.
Since only the rtl8187se part of the driver supports QoS, the priority
of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185
cards.
rtl8180 is then unconditionally reading out the priority and finally crashes on
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this
patch:
idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries
"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got
initialized.
Cc: stable@vger.kernel.org
Reported-by: pa@panix.com
Tested-by: pa@panix.com
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220422145228.7567-1-alexander@wetzel-home.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 24f5e38a13b5ae2b6105cda8bb47c19108e62a9a ]
Many Intel based platforms face system random freeze after commit
9e2fd29864 ("rtw88: add napi support").
The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status
Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.
Fixes: 9e2fd29864 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131
BugLink: https://bugs.launchpad.net/bugs/1927808
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8b144dedb928e4e2f433a328d58f44c3c098d63e upstream.
Syzbot reports the following WARNING:
[200~raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10
warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10
Hardware initialization for the rtl8188cu can run for as long as 350 ms,
and the routine may be called with interrupts disabled. To avoid locking
the machine for this long, the current routine saves the interrupt flags
and enables local interrupts. The problem is that it restores the flags
at the end without disabling local interrupts first.
This patch fixes commit a53268be0c ("rtlwifi: rtl8192cu: Fix too long
disable of IRQs").
Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Fixes: a53268be0c ("rtlwifi: rtl8192cu: Fix too long disable of IRQs")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clang warns:
drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:901:6: warning:
variable 'place' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
if (chnl > 14) {
^~~~~~~~~
drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:909:9: note:
uninitialized use occurs here
return place;
^~~~~
drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:901:2: note: remove
the 'if' if its condition is always true
if (chnl > 14) {
^~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:899:10: note:
initialize the variable 'place' to silence this warning
u8 place;
^
= '\0'
1 warning generated.
Commit 369956ae57 ("rtlwifi: rtl8192de: Remove redundant variable
initializations") removed the initialization of place but it appears
that this removal was in the wrong function.
_rtl92c_phy_get_rightchnlplace() returns place's value at the end of the
function so now if the if statement is false, place never gets
initialized. Add that initialization back to address the warning.
place's initialization is not necessary in
rtl92d_get_rightchnlplace_for_iqk() as place is only used within the if
statement so it can be removed, which is likely what was intended in the
first place.
Fixes: 369956ae57 ("rtlwifi: rtl8192de: Remove redundant variable initializations")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210823222014.764557-1-nathan@kernel.org
The rtw_pci_init_rx_ring function is only ever called with a fixed
constant or RTK_MAX_RX_DESC_NUM for the "len" argument. Since this
constant is defined as 512, the "if (len > TRX_BD_IDX_MASK)" check
can never happen (TRX_BD_IDX_MASK is defined as GENMASK(11, 0) or in
other words as 4095).
So, remove this check.
The true motivation for this patch is to silence a false Coverity
warning.
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Len Baker <len.baker@gmx.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210731163546.10753-1-len.baker@gmx.com
Current flow will lead to null ptr access because of trying
to get the size of freed probe-request packets. We store the
information of packet size into rsvd page instead and also fix
the size error issue, which will cause unstable behavoir of
sending probe request by wow firmware.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210728014335.8785-6-pkshih@realtek.com
The kernel test robot reports undefined reference after we report wakeup
reason to mac80211. This is because CONFIG_PM is not defined in the testing
configuration file. In fact, functions within wow.c are used if CONFIG_PM
is defined, so use CONFIG_PM to decide whether we build this file or not.
The reported messages are:
hppa-linux-ld: drivers/net/wireless/realtek/rtw88/wow.o: in function `rtw_wow_show_wakeup_reason':
>> (.text+0x6c4): undefined reference to `ieee80211_report_wowlan_wakeup'
>> hppa-linux-ld: (.text+0x6e0): undefined reference to `ieee80211_report_wowlan_wakeup'
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210728014335.8785-4-pkshih@realtek.com
In current wow flow, driver calls rtw_wow_fw_start and sleep for 100ms,
to wait firmware finish preliminary work and then update the value of
WOWLAN_WAKE_REASON register to zero. But later firmware will start wow
function with power-saving mode, in which mode the value of
WOWLAN_WAKE_REASON register is 0xea. So driver may get 0xea value and
return fail. We use read_poll_timeout instead to check the value to avoid
this issue.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210728014335.8785-2-pkshih@realtek.com
We find the power sequence of system suspend flow don't meet
the criteria when using 8822CE-VR chip by rfe-type 6, because the
reference clock form host is sometimes late. To avoid the behavoir,
we keep CLKREQ# signal to low during suspend to make sure the reference
clock arrival in time.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210727100503.31626-1-pkshih@realtek.com
The TX A-MPDU aggregation is not handled in the driver since the
ieee80211_start_tx_ba_session has never been started properly.
Start and stop the TX BA session by tracking the TX aggregation
status of each TID. Fix the ampdu_action and the tx descriptor
accordingly with the given TID.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210804151325.86600-1-chris.chiu@canonical.com
There will be crazy numbers of interrupts triggered by 8188cu and
8192cu module, around 8000~10000 interrupts per second, on the usb
host controller. Compare with the vendor driver source code, it's
mapping to the configuration CONFIG_USB_INTERRUPT_IN_PIPE and it is
disabled by default.
Since the interrupt transfer is neither used for TX/RX nor H2C
commands. Disable it to avoid the excessive amount of interrupts
for the 8188cu and 8192cu module which I only have for verification.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Tested-by: reto.schneider@husqvarnagroup.com
Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210701163354.118403-1-chris.chiu@canonical.com
Don't populate arrays the stack but instead make them static const. Replace
array channel_info with channel_all since it contains the same data as
channel_all. Makes object code smaller by 961 bytes.
Before:
text data bss dec hex filename
128147 44250 1024 173421 2a56d ../realtek/rtlwifi/rtl8192de/phy.o
After
text data bss dec hex filename
127122 44314 1024 172460 2a1ac ../realtek/rtlwifi/rtl8192de/phy.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210803144949.79433-2-colin.king@canonical.com
Johannes berg says:
====================
Lots of changes:
* aggregation handling improvements for some drivers
* hidden AP discovery on 6 GHz and other HE 6 GHz
improvements
* minstrel improvements for no-ack frames
* deferred rate control for TXQs to improve reaction
times
* virtual time-based airtime scheduler
* along with various little cleanups/fixups
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring array fields.
The size argument to memset() is bytes, but the array element size
of curvecount_val is u32, so "CV_CURVE_CNT * 2" was only 1/4th of the
contents of curvecount_val. Adjust memset() to wipe full buffer size.
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210617171317.3410722-1-keescook@chromium.org
8821CE with ASPM cannot work properly on Protempo Ltd L116HTN6SPW. Add a
quirk to disable the cap.
The reporter describes the symptom is that this module (driver) causes
frequent freezes, randomly but usually within a few minutes of running
(thus very soon after boot): screen display remains frozen, no response
to either keyboard or mouse input. All I can do is to hold the power
button to power off, then reboot.
Reported-by: Paul Szabo <psz2036@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210607012254.6306-1-pkshih@realtek.com
Use device coredump framework instead of print_hex_dump to support
FW crash dump. Pass data to the framework if preparing and dumping
are successful. The framework will take the ownership of the data.
The data will be freed after the framework determines its lifetime
is over. A new coredump will not work if the previous one still
exists.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210528032901.12927-2-pkshih@realtek.com
