| Age | Commit message (Collapse) | Author |
|---|
|
We allow platform to disable 6 GHz on chips, which supports 6 GHz, through
BIOS. Driver will evaluate Realtek acpi DSM with RTW89_ACPI_DSM_FUNC_6G_DIS
(function 3) to get whether 6 GHz should be disabled.
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/20230602150556.36777-3-pkshih@realtek.com
|
|
We refine to check if supported bands of NL80211_BAND_2GHZ and
NL80211_BAND_5GHZ exist before freeing their iftype_data. For
now, it does not really encounter problems because all current
chips support both 2 GHz and 5 GHz. But, driver actually allows
chips to declare whether 2/5 GHz are supported or not. In case
some future chips really don't support them, we refine this code.
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/20230602150556.36777-2-pkshih@realtek.com
|
|
RTL8851B firmware supports CRASH_TRIGGER feature from v0.29.41.0.
After this is configured, debugfs fw_crash can support type 1 on
RTL8851B to trigger firmware crash and verify L2 recovery through
simulation.
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/20230531060713.57203-5-pkshih@realtek.com
|
|
The key condition to check in wrapper of setting TX power is whether entity
is active or not. Before entity is active, we restrict TX power from being
set by outside callers, e.g. SAR/regulatory.
We mark entity as inactive when powering off MAC. Then, we will mark it as
active when we initialize HW channel stuffs after MAC power on. Although we
can get an active entity after leaving idle phase, TX power doesn't be set
well for default channel until stack set target channel for connection. It
causes that RF things cannot use better TX power during this interval.
Below are some cases which may encounter this or a similar situation.
* hw scan process before connection
As described above.
* right after restart hardware process (SER L2)
HW stuffs of target channel is initialized after mac80211 restart
hardware, but we unexpectedly need to wait one more command to set
channel again or to set TX power.
To fix it and improve RF behavior in that interval, during setting channel,
we don't need to check entity state before setting TX power, which actually
is used to restrict outside callers. It means we call chip ops directly to
replace the wrapper call. Then, TX power can be initialized as long as we
initialize/setup HW stuffs on one channel.
Besides, all chips should configure ops of setting TX power, so we remove
trivial check on pointer.
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/20230531060713.57203-4-pkshih@realtek.com
|
|
We now support RTL8851B which has only single RF path. For chip with
single RF path, TX power page is valid only in single path section.
So, we refine debugfs txpwr table to access TX power page according
to RF path number of runtime chip. It can prevent us from reading
beyond valid sections.
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/20230531060713.57203-3-pkshih@realtek.com
|
|
This enables hw_scan for 8851b after firmware version 0.29.37.1.
Extend the channel info struct with padding zeros so newer firmware
can work properly, this change is backward compatible with older
firmware.
Signed-off-by: Po-Hao Huang <phhuang@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/20230531060713.57203-2-pkshih@realtek.com
|
|
There are a number of upcoming things in both the stack and
drivers that would otherwise conflict, so merge wireless to
wireless-next to be able to avoid those conflicts.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Originally, add this check rule to prevent entering LPS if more than one
vif (in station mode) connect to AP. Since we have checked this by previous
commit, remove this redundant check.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230527082939.11206-4-pkshih@realtek.com
|
|
This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or
turn on dynamic PS controlled by driver and firmware. Though this would be
incorrect, it did work before because the flag is always recalculated until
the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS")
is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS
of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS.
Correct this by doing recalculation while BSS_CHANGED_PS is changed and
interface is added or removed. For now, it is allowed to enter PS only if
single one station vif is working, and it could possible to have PS per
vif after firmware can support it. Without this fix, driver doesn't
enter PS anymore that causes higher power consumption.
Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Cc: stable@vger.kernel.org # 6.1+
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230527082939.11206-3-pkshih@realtek.com
|
|
This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or
turn on dynamic PS controlled by driver and firmware. Though this would be
incorrect, it did work before because the flag is always recalculated until
the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS")
is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS
of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS.
Correct this by doing recalculation while BSS_CHANGED_PS is changed and
interface is added or removed. It is allowed to enter PS only if single
one station vif is working. Without this fix, driver doesn't enter PS
anymore that causes higher power consumption.
Fixes: bcde60e599fb ("rtw88: remove misleading module parameter rtw_fw_support_lps")
Cc: stable@vger.kernel.org # 6.1+
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230527082939.11206-2-pkshih@realtek.com
|
|
Although rtl_get_hdr was added in commit 3dad618b7b92 ("rtlwifi: Change
wifi.h for rtl8192se and rtl8192de"), it is currently not being utilized
in some areas. This commit replaces the open code with the rtl_get_hdr()
function.
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230527114954.3281-1-claudiajkang@gmail.com
|
|
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: a82dfd33d1237 ("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
|
|
There is a spelling mistake in a literal string. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522085924.913649-1-colin.i.king@gmail.com
|
|
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
|
|
RX descriptor is to provide basic and important information related to
packets, such as packet size, security, MAC ID and so on. Change to use
struct to access these fields, and not 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-5-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
|
|
If received packet type is PPDU status, RX info provides information
attached by MAC hardware, and mention how long BB information attached.
This conversion 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-3-pkshih@realtek.com
|
|
newer chips
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
|
|
Since 8851BE is ready, so add 8851BE to Makefile and Kconfig. Currently,
it can support STA, AP and monitor modes with good performance.
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-8-pkshih@realtek.com
|
|
8851B has the same issue: management frames get stuck when WiFi
chip enters low PS mode, so we also add notify wake function to
trigger WiFi chip wake before forwarding management frames.
Signed-off-by: Chin-Yen Lee <timlee@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/20230519031500.21087-7-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
|
|
RF configurations include RF calibrations and getting thermal value.
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-5-pkshih@realtek.com
|
|
These configurations include path control, TX grant, TX scheduler,
register-based H2C/C2H and so on.
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-4-pkshih@realtek.com
|
|
These capabilities include helpers of BT coexistence, RX PPDU status
parser, DIG (dynamic initial gain) and CFO (center frequency offset)
settings.
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-3-pkshih@realtek.com
|
|
Get TX power value from tables according to selected country and channel,
and set proper power to registers.
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-2-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
|
|
Wire up RTL8723DS chipset support using the rtw88 SDIO HCI code as well
as the existing RTL8723D chipset code.
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-5-martin.blumenstingl@googlemail.com
|
|
The efuse of the SDIO RTL8723DS chip has only one known member: the mac
address is at offset 0x11a. Add a struct rtw8723ds_efuse describing this
and use it for copying the mac address when the SDIO bus is used.
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-3-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
|
|
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
|
|
RX DCK is receiver DC calibration. With this calibration, we have proper
DC offset to reflect correct received signal strength indicator. Do this
calibration when bringing up interface and going to run on AP channel.
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-2-pkshih@realtek.com
|
|
Parse efuse content to recognize MAC address, RFE type, XTAL offset and
so on. And, parse offset of PHY capability to retrieve TX power
calibration 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-7-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
|
|
Add basic functions to power on chip and enable and access BB/RF, as
well as reset and hardware settings of BB.
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-5-pkshih@realtek.com
|
|
Add 8851B specific parameters of BT coexistence. Since 8851B has special
two antenna hardware module with antenna diversity, BT coexistence needs
to recognize this, so add some fields to store these information for
further use.
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-4-pkshih@realtek.com
|
|
Though 8851BE is a 1x1 chip, but it has two antenna hardware module that
needs additional configuration to help choose antenna we are going to use.
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-3-pkshih@realtek.com
|
|
8851B hardware version A and B use different firmware, but register version
code of these two are the same, so add this helper to read efuse version to
determine which version is installed.
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-2-pkshih@realtek.com
|
|
The Allwinner sunxi-mmc controller cannot handle word (16 bit)
transfers. So and sdio_{read,write}w fails with messages like the
following example using an RTL8822BS (but the same problems were also
observed with RTL8822CS and RTL8723DS chips):
rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13
sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2
sunxi-mmc 4021000.mmc: map DMA failed
rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22
Use two consecutive single byte accesses for word operations instead. It
turns out that upon closer inspection this is also what the vendor
driver does, even though it does have support for sdio_{read,write}w. So
we can conclude that the rtw88 chips do support word access but only on
SDIO controllers that also support it. Since there's no way to detect if
the controller supports word access or not the rtw88 sdio driver
switches to the easiest approach: avoiding word access.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/
Reported-by: Rudi Heitbaum <rudi@heitbaum.com>
Link: https://github.com/LibreELEC/LibreELEC.tv/pull/7837#issue-1708469467
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
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/20230515195043.572375-1-martin.blumenstingl@googlemail.com
|
|
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
|
|
When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
probability of failure, which shows "authentication with ... timed out".
Through debugging, it was found that the RCR register has been inexplicably
modified to an incorrect value, resulting in the nic not being able to
receive authenticated frames.
To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
the RCR value every time the register is written, and use it the next
time the register need to be modified.
Signed-off-by: Yun Lu <luyun@kylinos.cn>
Link: https://lore.kernel.org/all/20230427020512.1221062-1-luyun_611@163.com
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230512012055.2990472-1-luyun_611@163.com
|
|
qsel_to_ep[] can be assigned negative value, so change type from 'u8' to
'int'. Otherwise, Smatch static checker warns:
drivers/net/wireless/realtek/rtw88/usb.c:219 rtw_usb_parse() warn:
assigning (-22) to unsigned variable 'rtwusb->qsel_to_ep[8]'
Cc: stable@vger.kernel.org
Fixes: a6f187f92bcc ("wifi: rtw88: usb: fix priority queue to endpoint mapping")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/linux-wireless/c3f70197-829d-48ed-ae15-66a9de80fa90@kili.mountain/
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508085539.46795-1-pkshih@realtek.com
|
|
The ieee80211_ops::sta_rc_update must be atomic, because
ieee80211_chan_bw_change() holds rcu_read lock while calling
drv_sta_rc_update(), so create a work to do original things.
Voluntary context switch within RCU read-side critical section!
WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318
rcu_note_context_switch+0x571/0x5d0
CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G W OE
Workqueue: phy3 ieee80211_chswitch_work [mac80211]
RIP: 0010:rcu_note_context_switch+0x571/0x5d0
Call Trace:
<TASK>
__schedule+0xb0/0x1460
? __mod_timer+0x116/0x360
schedule+0x5a/0xc0
schedule_timeout+0x87/0x150
? trace_raw_output_tick_stop+0x60/0x60
wait_for_completion_timeout+0x7b/0x140
usb_start_wait_urb+0x82/0x160 [usbcore
usb_control_msg+0xe3/0x140 [usbcore
rtw_usb_read+0x88/0xe0 [rtw_usb
rtw_usb_read8+0xf/0x10 [rtw_usb
rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core
rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core
drv_sta_rc_update+0x7c/0x160 [mac80211
ieee80211_chan_bw_change+0xfb/0x110 [mac80211
ieee80211_change_chanctx+0x38/0x130 [mac80211
ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211
ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211
ieee80211_chswitch_work+0x95/0x170 [mac80211
process_one_work+0x201/0x410
worker_thread+0x4a/0x3b0
? process_one_work+0x410/0x410
kthread+0xe1/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
</TASK>
Cc: stable@vger.kernel.org
Fixes: c1edc86472fc ("rtw88: add ieee80211:sta_rc_update ops")
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Link: https://lore.kernel.org/linux-wireless/f1e31e8e-f84e-3791-50fb-663a83c5c6e9@lwfinger.net/T/#t
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508085429.46653-1-pkshih@realtek.com
|
|
Though SER can recover this case, traffic can get stuck for a while. Fix it
by adjusting page quota to avoid hardware access null page of CMAC/DMAC.
Fixes: a1cb097168fa ("wifi: rtw89: 8852b: configure DLE mem")
Fixes: 3e870b481733 ("wifi: rtw89: 8852b: add HFC quota arrays")
Cc: stable@vger.kernel.org
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Link: https://github.com/lwfinger/rtw89/issues/226#issuecomment-1520776761
Link: https://github.com/lwfinger/rtw89/issues/240
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230426034737.24870-1-pkshih@realtek.com
|
|
For 8852CE, there is abnormal state called CMDPSR_FRZTO,
which occasionally happens in some platforms, and could be
found by firmware and fixed in current SER flow, so we add
suppress function to avoid verbose message for this resolved case.
Signed-off-by: Chin-Yen Lee <timlee@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/20230508084335.42953-4-pkshih@realtek.com
|
|
Newer FW re-design SER (syetem error recovery) L1 (level 1) flow.
New L1 flow will expect two extra states before original L1 flow.
* Before:
fw --- M1 --> driver
fw <-- M2 --- driver
fw --- M3 --> driver
fw <-- M4 --- driver
fw --- M5 --> driver
* After:
fw --- pre-M0 --> driver
fw <-- post-M0 --- driver
fw --- M1 --> driver
fw <-- M2 --- driver
fw --- M3 --> driver
fw <-- M4 --- driver
fw --- M5 --> driver
Then before M1, FW gets one more interval to deal with things that FW
should have handled well. To consider backward/forward compatibility,
FW and driver won't change flow from M1 to M5. (only except that halt
trigger control will change a little bit.) So, there will be two differnt
starting points of SER L1.
* old FW: SER L1 starts from M1
* new FW: SER L1 starts from pre-M0
Then, driver adds the new SER L1 entry and also keep the original one
instead of changing it.
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/20230508084335.42953-3-pkshih@realtek.com
|
