Age | Commit message (Collapse) | Author |
|
The priority table should be changed according to what the in using
Bluetooth application is. To avoid Bluetooth audio + HID (mouse) will
trigger the lag experience, update the priority table.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241019063131.9462-1-pkshih@realtek.com
|
|
This is one of three drivers that trigger -Wenum-compare-conditional warnings
with clang:
drivers/net/wireless/realtek/rtw89/core.c:1806:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1806 | return eht ? NL80211_RATE_INFO_EHT_GI_0_8 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1807 | NL80211_RATE_INFO_HE_GI_0_8;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1810:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1810 | return eht ? NL80211_RATE_INFO_EHT_GI_1_6 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1811 | NL80211_RATE_INFO_HE_GI_1_6;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1813:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1813 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1814 | NL80211_RATE_INFO_HE_GI_3_2;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1818:15: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1818 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1819 | NL80211_RATE_INFO_HE_GI_3_2;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this case, all four warnings can be easily avoided by splitting the
function into two separate ones, in a way that helps readability as well,
at the expense of a few extra source lines.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241018152311.4023979-1-arnd@kernel.org
|
|
Some used firmware are missing to be added to MODULE_FIRMWARE().
Add them accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241018055651.21166-1-pkshih@realtek.com
|
|
The previous implementation included an unnecessary else
condition paired with a continue statement. Since a check
is already performed to determine if the band is either
2G or 5G, the else condition will never be triggered.
We can remove this check.
Signed-off-by: Mohammed Anees <pvmohammedanees2003@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241017080638.13074-1-pvmohammedanees2003@gmail.com
|
|
If 6 GHz of a country is marked as N/A in our regd map,
we block 6 GHz channels now.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016134457.9375-1-pkshih@realtek.com
|
|
Specific PCI subsystem ID (SSID) of WiFi cards is used by specific
customer who want to enable various features with different arguments.
Define PCI SSID quirks tables to enable thermal protection with two kinds
of thermal values for 110 and 120 degree Celsius.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-3-pkshih@realtek.com
|
|
To prevent chip overheating, reduce TX duty as the mechanism of thermal
protection. When temperature is raising over a threshold, send a firmware
command to reduce TX duty. If temperature is still raising, higher level
is adopted to have lower active duration.
The equation and unit of thermal values are different from chip to chip,
so define constant thresholds of thermal value to corresponding absolute
temperature of 110 and 120 degree Celsius.
Latter patch will decide which thermal threshold is adopted, and current
is still not enable thermal protection.
For debugging, add a flag to disable_dm that thermal protection can be
disabled to clarify low throughput in field.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-2-pkshih@realtek.com
|
|
In order to update the right link information, call the update
rate_control_rate_update() with the right link_sta, and then
pass that through to the driver's sta_rc_update() method. The
software rate control still doesn't support it, but that'll be
skipped by not having a rate control ref.
Since it now operates on a link sta, rename the driver method.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241007144851.5851b6b5fd41.Ibdf50d96afa4b761dd9b9dfd54a1147e77a75329@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
SAR subband
The UNII-4 uses the same SAR value of UNII-3, so add UNII-4 frequency
range and change the enum name to represent UNII-3 and UNII-4.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009071619.16841-1-pkshih@realtek.com
|
|
The return type of error code of rtw8852c_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1626056 ("Overflowed constant")
Addresses-Coverity-ID: 1627945 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-7-pkshih@realtek.com
|
|
The return type of error code of rtw8852bt_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1630962 ("Overflowed constant")
Addresses-Coverity-ID: 1632126 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-6-pkshih@realtek.com
|
|
The return type of error code of rtw8852b_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1622433 ("Overflowed constant")
Addresses-Coverity-ID: 1630710 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-5-pkshih@realtek.com
|
|
The return type of error code of rtw8851b_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1624679 ("Overflowed constant")
Addresses-Coverity-ID: 1630970 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-4-pkshih@realtek.com
|
|
poll_{tx,rx}dma_ch_idle()
The return type of error code of read_poll_timeout() and
rtw89_pci_poll_{tx,rx}dma_ch_idle_ax() and must be 'int'.
Correct them accordingly.
Addresses-Coverity-ID: 1622341 ("Overflowed constant")
Addresses-Coverity-ID: 1627296 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-3-pkshih@realtek.com
|
|
The type of tsf arithmetic is
u64 += u16 * int;
When (u16 * int) is larger than 0x7FFFFFFF, the value casting to u64 with
sign-extension will become all 1 in upper 32 bits part.
To meet the case, u16 value should be larger than 20491
(0x7FFFFFFF / 104800). Fortunately the meaning of 20491 is delay time of
WoWLAN net detection in unit of second, so 20491 seconds (5.7 hours)
might not a real case we can meet.
Addresses-Coverity-ID: 1620910 ("Unintended sign extension")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-2-pkshih@realtek.com
|
|
This ID appears to be RTL8188SU, not RTL8192DU. This is the wrong driver
for RTL8188SU. The r8712u driver from staging handles this ID.
I think this ID comes from the original rtl8192du driver from Realtek.
I don't know if they added it by mistake, or it was actually used for
two different chips.
RTL8188SU with this ID exists in the wild. RTL8192DU with this ID
probably doesn't.
Fixes: b5dc8873b6ff ("wifi: rtlwifi: Add rtl8192du/sw.c")
Cc: stable@vger.kernel.org # v6.11
Closes: https://github.com/lwfinger/rtl8192du/issues/105
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/40245564-41fe-4a5e-881f-cd517255b20a@gmail.com
|
|
RTL8822CU, RTL8822BU, and RTL8821CU don't need BIT_EN_PRE_CALC.
In fact, RTL8822BU in USB 3 mode doesn't pass all the frames to the
driver, resulting in much lower download speed than normal:
$ iperf3 -c 192.168.0.1 -R
Connecting to host 192.168.0.1, port 5201
Reverse mode, remote host 192.168.0.1 is sending
[ 5] local 192.168.0.50 port 43062 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 26.9 MBytes 225 Mbits/sec
[ 5] 1.00-2.00 sec 7.50 MBytes 62.9 Mbits/sec
[ 5] 2.00-3.00 sec 8.50 MBytes 71.3 Mbits/sec
[ 5] 3.00-4.00 sec 8.38 MBytes 70.3 Mbits/sec
[ 5] 4.00-5.00 sec 7.75 MBytes 65.0 Mbits/sec
[ 5] 5.00-6.00 sec 8.00 MBytes 67.1 Mbits/sec
[ 5] 6.00-7.00 sec 8.00 MBytes 67.1 Mbits/sec
[ 5] 7.00-8.00 sec 7.75 MBytes 65.0 Mbits/sec
[ 5] 8.00-9.00 sec 7.88 MBytes 66.1 Mbits/sec
[ 5] 9.00-10.00 sec 7.88 MBytes 66.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 102 MBytes 85.1 Mbits/sec 224 sender
[ 5] 0.00-10.00 sec 98.6 MBytes 82.7 Mbits/sec receiver
Don't set BIT_EN_PRE_CALC. Then the speed is much better:
% iperf3 -c 192.168.0.1 -R
Connecting to host 192.168.0.1, port 5201
Reverse mode, remote host 192.168.0.1 is sending
[ 5] local 192.168.0.50 port 39000 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 52.8 MBytes 442 Mbits/sec
[ 5] 1.00-2.00 sec 71.9 MBytes 603 Mbits/sec
[ 5] 2.00-3.00 sec 74.8 MBytes 627 Mbits/sec
[ 5] 3.00-4.00 sec 75.9 MBytes 636 Mbits/sec
[ 5] 4.00-5.00 sec 76.0 MBytes 638 Mbits/sec
[ 5] 5.00-6.00 sec 74.1 MBytes 622 Mbits/sec
[ 5] 6.00-7.00 sec 74.0 MBytes 621 Mbits/sec
[ 5] 7.00-8.00 sec 76.0 MBytes 638 Mbits/sec
[ 5] 8.00-9.00 sec 74.4 MBytes 624 Mbits/sec
[ 5] 9.00-10.00 sec 63.9 MBytes 536 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 717 MBytes 601 Mbits/sec 24 sender
[ 5] 0.00-10.00 sec 714 MBytes 599 Mbits/sec receiver
Fixes: 002a5db9a52a ("wifi: rtw88: Enable USB RX aggregation for 8822c/8822b/8821c")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/afb94a82-3d18-459e-97fc-1a217608cdf0@gmail.com
|
|
The early chips including RTL8852A, RTL8851B, RTL8852B and RTL8852BT have
interoperability problems of 36-bit DMA with some PCI hosts. Rollback
to 32-bit DMA by default, and only enable 36-bit DMA for tested platforms.
Since all Intel platforms we have can work correctly, add the vendor ID to
white list. Otherwise, list vendor/device ID of bridge we have tested.
Fixes: 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address")
Reported-by: Marcel Weißenbach <mweissenbach@ignaz.org>
Closes: https://lore.kernel.org/linux-wireless/20240918073237.Horde.VLueh0_KaiDw-9asEEcdM84@ignaz.org/T/#m07c5694df1acb173a42e1a0bab7ac22bd231a2b8
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Marcel Weißenbach <mweissenbach@ignaz.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240924021633.19861-1-pkshih@realtek.com
|
|
The older firmware of 8852A and 8852B can't receive packets via
CPU IO function and will lead to WoWLAN fail if calling it.
So use firmware feature to distinguish.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241004065408.10261-1-pkshih@realtek.com
|
|
To parsing firmware report correctly, driver need to re-order the report
index to match with different chips and different Wi-Fi firmware version.
Use wrong index to parse the report will lead the coexistence run into
wrong mechanism.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-5-pkshih@realtek.com
|
|
Some Bluetooth device will make up connection as PAN link, though the
connection is idle, it will still report the PAN link is active. The
coexistence mechanism will enable TDMA to protect the PAN, it makes
Wi-Fi throughput degrade at least 50%. But the link is idle, don't
need so much bandwidth. Add TDMA case to let Wi-Fi can do traffic 80%
bandwidth.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-4-pkshih@realtek.com
|
|
Reorder Bluetooth firmware related event index, it should be the same
with Wi-Fi firmware definition. To fix coexistence can not recognize
Bluetooth PAN(Personal area network) profile correctly, modified the
related logic.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-3-pkshih@realtek.com
|
|
Update coexistence priority setting for Wi-Fi scanning channel, the new
setting will allow Wi-Fi do RX while Bluetooth audio is not busy. Forced
to set new TDMA policy while RF calibration request come, to make sure
the calibration can do well, and switch to normal setting while the
calibration is done. Remove the code that no longer use.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-2-pkshih@realtek.com
|
|
In STA+AP concurrent mode, performing a scan operation on one vif
temporarily stops beacons on the other. When the scan is completed,
beacons are enabled again with BSS_CHANGED_BEACON_ENABLED.
We can observe that no beacons are being sent when just
rtl8xxxu_start_tx_beacon() is being called.
Thus, also perform update_beacon_work in order to restore beaconing.
Fixes: cde8848cad0b ("wifi: rtl8xxxu: Add beacon functions")
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240930084955.455241-1-martin.kaistra@linutronix.de
|
|
In range test, the RSSI is helpful to check attenuation of cable and align
difference between environments. Since data packets can be transmitted with
different rate and power, the RSSI of all packets can be variant.
Oppositely beacon is transmitted with the same rate and power, so beacon
RSSI will be relatively invariant, and more helpful to diagnose problems.
The output of beacon RSSI in unit of dBm looks like:
Beacon: 19 (-33 dBm), TF: 0
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240927013512.7106-1-pkshih@realtek.com
|
|
Originally, we have an active flag to record whether we have set PHY once.
After impending MLO support, there will be dual-PHY and they can be set
individually on Wi-Fi 7 chips. So, we now have active flag per PHY and
handle them individually.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925020119.13170-3-pkshih@realtek.com
|
|
To support MLO, we initialize things on dual HW bands of Wi-Fi 7 chip.
And, each link will indicate which HW band it's bound to. So, in link
control flow, we control major things based on target link's HW band
instead of hardcode like RTW89_PHY_X or RTW89_MAC_X.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925020119.13170-2-pkshih@realtek.com
|
|
compatibility
Read calibration value of PCI RX offset, and set to manual mode as the
value at PCI probe to prevent abnormal calibration results at runtime.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925013901.9835-5-pkshih@realtek.com
|
|
To use manual mode to set value of filter out EQ, read the source value of
filter out EQ coded in gray code, and write to the target register in
binary number. The function to convert from gray code to binary number is
wrong originally, causing unexpected EQ, so fix it.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925013901.9835-4-pkshih@realtek.com
|
|
For adaption EQ circuit, this HW design and affected by EIEOS (Electrical
Idle Exit Order Set) amplitude from platform and process from IC, so
disable EQ to improve that.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925013901.9835-3-pkshih@realtek.com
|
|
The PCI settings aren't always persistent after chip suspends, so
reconfigure the settings after chip resumes. Since most of these settings
are the same, consolidate them into a function to avoid missing somewhere.
Fix the missing case of 8922AE resume flow.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925013901.9835-2-pkshih@realtek.com
|
|
rtw8703b_query_rx_desc(), rtw8723d_query_rx_desc(),
rtw8821c_query_rx_desc(), rtw8822b_query_rx_desc(), and
rtw8822c_query_rx_desc() are almost identical, so replace them all with
a single function, rtw_rx_query_rx_desc().
Also, access the RX descriptor using a struct with __le32 members and
le32_get_bits().
Tested with RTL8811CU, RTL8811AU, and RTL8812AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Tested-by: Ping-Ke Shih <pkshih@realtek.com> # RTL8723DE and RTL8822CE
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/913f1747-38fc-4409-85a4-57bb9cee506b@gmail.com
|
|
_dpk_dgain_read()
The return value of _dpk_dgain_read() is not used afterward, so remove
it safely.
Addresses-Coverity-ID: 1504753 ("Unused value")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240919081216.28505-4-pkshih@realtek.com
|
|
For the case of DBCC enabled and fwrole version 0, the local variable
wl_rinfo.dbcc_2g_phy might not be set by following for-loop, leading
uninitialized variable before using.
Addresses-Coverity-ID: 1586724 ("Uninitialized scalar variable")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240919081216.28505-3-pkshih@realtek.com
|
|
The return value of ieee80211_probereq_get() might be NULL, so check it
before using to avoid NULL pointer access.
Addresses-Coverity-ID: 1529805 ("Dereference null return value")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240919081216.28505-2-pkshih@realtek.com
|
|
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
|
|
Refactor STA related functions, e.g. add/assoc/disassoc/disconnect/remove
to separate most link stuffs into sub-functions for MLO reuse.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-7-pkshih@realtek.com
|
|
Refactor VIF related functions, e.g. add/remove/assoc/mapping
to separate most link stuffs into sub-functions for MLO reuse.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-6-pkshih@realtek.com
|
|
Tweak code to not always access sta->deflink directly. Instead,
according to link_id, read target link_sta from sta->link[].
For now, rtwsta_link->link_id keeps 0. When driver starts to
support MLO, the link_id will be assigned.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-5-pkshih@realtek.com
|
|
Tweak code to not always access vif->bss_conf directly. Instead,
according to link_id, read target bss_conf from vif->link_conf[].
For now, rtwvif_link->link_id keeps 0. When driver starts to
support MLO, the link_id will be assigned.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-4-pkshih@realtek.com
|
|
This is an intermediate version that is separated from subsequent major
MLO changes, so some functions' namings are not really determined here.
e.g. struct rtw89_sta_link *sta_to_rtwsta_safe(struct ieee80211_sta *sta)
No logic is changed.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-3-pkshih@realtek.com
|
|
This is an intermediate version that is separated from subsequent major
MLO changes, so some functions' namings are not really determined here.
e.g. struct rtw89_vif_link *vif_to_rtwvif_safe(struct ieee80211_vif *vif)
No logic is changed.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-2-pkshih@realtek.com
|
|
When removing kernel modules by:
rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core
Driver uses skb_queue_purge() to purge TX skb, but not report tx status
causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue()
to correct this.
Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing
between TX work and purge TX queue, flush and destroy TX work in advance.
wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local
choice (Reason: 3=DEAUTH_LEAVING)
------------[ cut here ]------------
Have pending ack frames!
WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691
ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
CPU: 3 PID: 9232 Comm: rmmod Tainted: G C
6.10.1-200.fc40.aarch64 #1
Hardware name: pine64 Pine64 PinePhone Braveheart
(1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
sp : ffff80008c1b37b0
x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000
x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0
x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff
x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000
x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000
x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964
x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0
x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000
Call trace:
ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
idr_for_each+0x74/0x110
ieee80211_free_hw+0x44/0xe8 [mac80211]
rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]
sdio_bus_remove+0x44/0x180
device_remove+0x54/0x90
device_release_driver_internal+0x1d4/0x238
driver_detach+0x54/0xc0
bus_remove_driver+0x78/0x108
driver_unregister+0x38/0x78
sdio_unregister_driver+0x2c/0x40
rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]
__do_sys_delete_module.isra.0+0x190/0x338
__arm64_sys_delete_module+0x1c/0x30
invoke_syscall+0x74/0x100
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x3c/0x158
el0t_64_sync_handler+0x120/0x138
el0t_64_sync+0x194/0x198
---[ end trace 0000000000000000 ]---
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/CALeDE9OAa56KMzgknaCD3quOgYuEHFx9_hcT=OFgmMAb+8MPyA@mail.gmail.com/
Tested-by: Ping-Ke Shih <pkshih@realtek.com> # 8723DU
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240822014255.10211-2-pkshih@realtek.com
|
|
These are never modified, so make them const:
card_enable_flow_8703b
card_disable_flow_8703b
rtw8703b_ops
rtw8723d_ops
card_enable_flow_8723d
card_disable_flow_8723d
trans_carddis_to_cardemu_8821c
trans_cardemu_to_act_8821c
trans_act_to_cardemu_8821c
trans_cardemu_to_carddis_8821c
card_enable_flow_8821c
card_disable_flow_8821c
rtw8821c_dig
page_table_8821c
rqpn_table_8821c
prioq_addrs_8821c
rtw8821c_ops
card_enable_flow_8822b
card_disable_flow_8822b
prioq_addrs_8822b
rtw8822b_ops
rtw8822b_edcca_th
card_enable_flow_8822c
card_disable_flow_8822c
prioq_addrs_8822c
rtw8822c_ops
rtw8822c_edcca_th
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/dae7994f-3491-40de-b537-ebf68df084bb@gmail.com
|
|
Update DACK (digital-to-analog converters calibration) log to v2 by
firmware C2H events.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240913071340.41822-6-pkshih@realtek.com
|
|
Print out IQ signal calibration log from firmware C2H events.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240913071340.41822-5-pkshih@realtek.com
|
|
TSSI is short for transmitter signal strength indication. Print out the
TSSI log from firmware C2H events.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240913071340.41822-4-pkshih@realtek.com
|
|
RX DCK stands for receiver DC calibration. The v1 format adds a field to
indicate the calibration is for operation channel or an average value for
all scanning channels. Update the format accordingly, and increase
firmware format sequence to 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240913071340.41822-3-pkshih@realtek.com
|
|
Firmware needs more time to execute TSSI calibration command. Enlarge
timeout time accordingly, otherwise driver throws messages:
rtw89_8922ae 0000:03:00.0: failed to wait RF TSSI
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240913071340.41822-2-pkshih@realtek.com
|
|
Don't populate the read-only arrays params, toshiba_smid1, toshiba_smid2,
samsung_smid and lenovo_smid on the stack at run time, instead make them
static const.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240912135335.590464-1-colin.i.king@gmail.com
|