When receiving more rx packets than the kernel can handle the driver
drops the packets and issues an error message. This is bad for two
reasons. The logs are flooded with myriads of messages, but then time
consumed for printing messages in that critical code path brings down
the device. After some time of excessive rx load the driver responds
with:
rtw_8822cu 1-1:1.2: failed to get tx report from firmware
rtw_8822cu 1-1:1.2: firmware failed to report density after scan
rtw_8822cu 1-1:1.2: firmware failed to report density after scan
The device stops working until being replugged.
Fix this by lowering the priority to debug level and also by
ratelimiting it.
Fixes: a82dfd33d1 ("wifi: rtw88: Add common USB chip support")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230524103934.1019096-1-s.hauer@pengutronix.de
struct rtw89_btc_btf_tlv contains a one-byte member that is intended as a
flexible array:
In function 'fortify_memcpy_chk',
inlined from '_append_tdma' at drivers/net/wireless/realtek/rtw89/coex.c:1579:3:
include/linux/fortify-string.h:583:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
583 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Make this actually use a flexible array to let the compiler understand.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230523113241.2772811-1-arnd@kernel.org
The register-based H2C/C2H are used to exchange commands and events with
firmware. The exchange data is limited, but it is relatively simple,
because it can work before HCI initialization. To make these code clean,
use struct to access them. This patch doesn't change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522122513.13559-6-pkshih@realtek.com
PHY status IEs generated by BB hardware is to provide more detail
information related to received packets, such as RSSI and bandwidth.
To avoid type casting, change buf type from u8* to void* as well.
This patch doesn't change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522122513.13559-4-pkshih@realtek.com
The next generation chips use different RX descriptor format, so add
a chip_ops to hook suitable handlers. Also, the length of RX descriptor is
different, so add a variable to store the length according to chip and
descriptor content dynamically. Then, the code can be more general.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522122513.13559-2-pkshih@realtek.com
The register ranges of upcoming chips are different from current, and even
existing chips have different ranges, so support longer length to dump
registers. Then, user space can decide the ranges according to chip.
Since arbitrary length (e.g. 7) would be a little complicated, so simply
make length a multiple of 16. The output looks like
18620000h : 8580801f 82828282 82828282 080800fd
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230519031500.21087-6-pkshih@realtek.com
H2C of packet offload needs to wait FW ACK by C2H. But, it's possible
that packet offload happens during SER (system error recovery), e.g.
SER L2 which restarts HW. More, packet offload flow isn't deferrable.
So, the H2C wait may get `ret == 1` (unreachable).
However, the logic FW deals with packet offload is simple enough, just
clone content. It means that as long as the H2C is issued successfully,
the thing will succeed sooner or later. Therefore, after we add a debug
log when receiving ACK to packet offload, it would be acceptable that
during SER, packet offload don't really wait for ACK. And, if debugging,
we can still check its debug logs. Besides, we can expect that if we see
SER before receiving ACK to packet offload, those debug logs of the ACK
have a time difference.
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@kernel.org>
Link: https://lore.kernel.org/r/20230516082441.11154-4-pkshih@realtek.com
Some specific H2C (host to chip command) needs waiting until FW ACK by
C2H (chip to host event). However, during SER (system error recovery),
most interrupts are disabled, so we can't receive C2H immediately. It
causes this kind of H2C TX waits will always time out during SER.
To save time spent by SER, we don't do these redundant waits. And, to
make a difference from -ETIMEDOUT in other cases, we make the function
return 1 for SER case. When some H2C callers really catch `ret == 1` at
runtime, they can determine whether it's reasonable or not, and consider
how to resolve their flow if needed.
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@kernel.org>
Link: https://lore.kernel.org/r/20230516082441.11154-3-pkshih@realtek.com
The total_sta_assoc and the tdls_peer are used for statistics accodring
to stations' information. L2 (Level 2) SER (system error recovery) will
call ieee80211_restart_hw() which re-invokes sta_state ops. And then,
the total_sta_assoc and tdls_peer will be re-increased. In case wrong
statistics results, we reset them in SER L2 handling.
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@kernel.org>
Link: https://lore.kernel.org/r/20230516082441.11154-2-pkshih@realtek.com
RTL8723DS comes in two variant and each of them has their own SDIO ID:
- 0xd723 can connect two antennas. The WiFi part is still 1x1 so the
second antenna can be dedicated to Bluetooth
- 0xd724 can only connect one antenna so it's shared between WiFi and
Bluetooth
Add a new entry for the single antenna RTL8723DS (0xd724) which can be
found on the MangoPi MQ-Quad. Also rename the existing RTL8723DS entry
(0xd723) so it's name reflects that it's the variant with support for
two antennas.
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522202425.1827005-4-martin.blumenstingl@googlemail.com
rtw_sdio_rx_isr() is responsible for receiving data from the wifi chip
and is called from the SDIO interrupt handler when the interrupt status
register (HISR) has the RX_REQUEST bit set. After the first batch of
data has been processed by the driver the wifi chip may have more data
ready to be read, which is managed by a loop in rtw_sdio_rx_isr().
It turns out that there are cases where the RX buffer length (from the
REG_SDIO_RX0_REQ_LEN register) does not match the data we receive. The
following two cases were observed with a RTL8723DS card:
- RX length is smaller than the total packet length including overhead
and actual data bytes (whose length is part of the buffer we read from
the wifi chip and is stored in rtw_rx_pkt_stat.pkt_len). This can
result in errors like:
skbuff: skb_over_panic: text:ffff8000011924ac len:3341 put:3341
(one case observed was: RX buffer length = 1536 bytes but
rtw_rx_pkt_stat.pkt_len = 1546 bytes, this is not valid as it means
we need to read beyond the end of the buffer)
- RX length looks valid but rtw_rx_pkt_stat.pkt_len is zero
Check if the RX_REQUEST is set in the HISR register for each iteration
inside rtw_sdio_rx_isr(). This mimics what the RTL8723DS vendor driver
does and makes the driver only read more data if the RX_REQUEST bit is
set (which seems to be a way for the card's hardware or firmware to
tell the host that data is ready to be processed).
For RTW_WCPU_11AC chips this check is not needed. The RTL8822BS vendor
driver for example states that this check is unnecessary (but still uses
it) and the RTL8822CS drops this check entirely.
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522202425.1827005-2-martin.blumenstingl@googlemail.com
ath.git patches for v6.5. Major changes:
ath11k
* Multiple Basic Service Set Identifier (MBSSID) and Enhanced MBSSID
Advertisement (EMA) support in AP mode
Due to the firmware behavior with HT fixed rate setting,
HT fixed rate MCS with NSS > 1 are treated as NSS = 1
HT rates in the firmware and enables the HT fixed rate of
NSS = 1.
This leads to HT fixed rate is always configured for NSS = 1
even though the user sets NSS = 2 or > 1 HT fixed MCS in the
set bitrate command.
Currently HT fixed MCS is sent via WMI peer assoc command.
Fix this issue, by sending the HT fixed rate MCS in WMI peer
fixed param instead of sending in peer assoc command.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Maharaja Kennadyrajan <quic_mkenna@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230504092033.3542456-3-quic_mkenna@quicinc.com
Relocate the function ath11k_mac_bitrate_mask_num_ht_rates() definition
to call this function from other functions which helps to avoid the
compilation error (function not defined).
ht_mcs[] is 1 byte array and it is enough to use hweight8() instead
of hweight16(). Hence, fixed the same.
Tested on: Compile tested only.
Signed-off-by: Maharaja Kennadyrajan <quic_mkenna@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230504092033.3542456-2-quic_mkenna@quicinc.com
When vdev start/stop happens, response from firmware is received with delay
and hence there is a timeout before VDEV can be up/down.
Also, with maximum peers connected and when vdev stop occurs, firmware
will take time to clean up all the peers and vap queues.
In such cases as well, vdev start/stop response is sent by firmware with delay.
Increase the vdev setup timeout as recommended by firmware team.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-02903-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aishwarya R <quic_aisr@quicinc.com>
Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230428091041.20033-1-quic_rgnanase@quicinc.com
TSSI is transmitter signal strength indication, which is a close-loop
hardware circuit to feedback actual transmitting power as a reference for
next transmission.
When we setup channel to connect an AP, it does full calibration. When
switching bands or channels, it needs to reset hardware status to prevent
use wrong feedback of previous transmission.
To do TX power compensation reflecting current temperature, it loads tables
of compensation values into registers according to channel and band group.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230513054425.9689-4-pkshih@realtek.com
DPK is short for digital pre-distortion calibration. It can adjusts digital
waveform according to PA linear characteristics dynamically to enhance
TX EVM.
Do this calibration when we are going to run on AP channel. To prevent
power offset out of boundary, it monitors thermal and set proper boundary
to register.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230513054425.9689-3-pkshih@realtek.com
Set MAC/BB/RF registers according to channel we are going to set. In
additional, certain channels or bands need more deals, such as enable CCK
in 2 GHz band, spur elimination at certain frequencies.
The set channel helper is used to save/restore states before/after setting
channel, and does reset BB to prevent hardware getting stuck in abnormal
state during switching channel and receiving data.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230512061220.16544-6-pkshih@realtek.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
