The dynamic antenna gain (DAG) considers the country, meaning DAG can
be activated only when countries and regulatory domains allow it.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250306021144.12854-4-pkshih@realtek.com
TAS state switching mechanism now incorporates the TX ratio as a
decision parameter. The average power calculation has been improved
by using a higher resolution conversion from dBm to linear. During
scan or MCC operations, TAS state is forced to static SAR and
suspend the average power calculation. Additionally, TAS window
size depends on the regulatory domain and band to ensure compliance.
TAS is enabled when permitted by the regulatory domain and is
currently supported on the 8852CE.
For debugging, add a flag to disable_dm that can stop TAS mechanism.
Co-developed-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250306021144.12854-3-pkshih@realtek.com
Enhanced the dBm to linear conversion function to accommodate negative
dBm values and improved the precision from 1 dBm to 0.25 dBm.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250306021144.12854-2-pkshih@realtek.com
The interrupt status (ISR) bits of RX desc unavailable (RDU) for 8922AE
are B_BE_RDU_CH1_INT_V1 and B_BE_RDU_CH0_INT_V1. With wrong bits, if it
happens, driver can't recognize the situation and prompt a message.
Fix the definition accordingly.
Fixes: aa70f76120 ("wifi: rtw89: pci: generalize interrupt status bits of interrupt handlers")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250227131907.9864-1-pkshih@realtek.com
Once update driver blacklist of firmware, users' firmware might be in
the list, and then driver stops working. Since breaking users is not
expected, report a significant message instead of stopping.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250227131228.8457-5-pkshih@realtek.com
Add new fields band and port ID to make chips operating on the band and
port ID other than 0, so that multiple vif(s) can be working at the
same time.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250227131228.8457-3-pkshih@realtek.com
The role_maintain H2C command is to align operating mode of WiFi role,
such as STA or AP modes, between driver and firmware.
Use a struct to fill fields of this H2C command.
Don't change logic at all.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250227131228.8457-2-pkshih@realtek.com
For some packets, we could not get channel information from PPDU status.
And this causes wrong frequencies being reported. Parse the channel
information from IE if provided by AP to fix this.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250220064357.17962-1-pkshih@realtek.com
For 8852BTE, 8852CE, and 8922AE, TKIP encryption and decryption
will be handled by hardware. All other chips will retain their
existing software-based encryption and decryption.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250220062344.15836-1-pkshih@realtek.com
Make it print the TX power details for all RF paths, not just A and B,
and for all the rates supported by the chip, not just 1SS and 2SS
rates.
Also skip the RF paths and rates not supported by the chip.
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/ea65a978-a735-4c97-af82-d7fe26f95da1@gmail.com
Print information about the 3rd and 4th RF paths and about the 3rd
spatial stream.
Also, fix a small bug: don't show the average SNR and EVM for the OFDM
and HT/VHT rates when the rate is actually CCK 11M.
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/7c8e94e2-e034-40f3-bdaf-b000018b5573@gmail.com
Select the TX power tracking tables for RF paths C and D as well.
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/e1e532c9-8733-4ec8-84fe-ced4af6c08da@gmail.com
Set the MCS maps and the highest rates according to the number of
spatial streams the chip has. For RTL8814AU that is 3.
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/e86aa009-b5bf-4b3a-8112-ea5e3cd49465@gmail.com
Set the RX mask and the highest RX rate according to the number of
spatial streams the chip can receive. For RTL8814AU that is 3.
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/4e786f50-ed1c-4387-8b28-e6ff00e35e81@gmail.com
This function translates the rate number reported by the hardware into
something mac80211 can understand. It was ignoring the 3SS and 4SS HT
rates. Translate them too.
Also set *nss to 0 for the HT rates, just to make sure it's
initialised.
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/d0a5a86b-4869-47f6-a5a7-01c0f987cc7f@gmail.com
rtw_mac_power_switch() checks bit 8 of REG_SYS_STATUS1 to see if the
chip is powered on. This bit appears to be always on in the RTL8814AU,
so ignore it.
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/2f0fcffb-3067-4d95-a68c-f2f3a5a47921@gmail.com
Check size of struct mfw_hdr within firmware->size before type casting
to ensure to validly dereference fields from mfm_hdr pointer. Then,
check if signature field is equal to RTW89_MFW_SIG to assert current
is multi-firmware.
Addresses-Coverity-ID: 1494046 ("Untrusted loop bound")
Addresses-Coverity-ID: 1544385 ("Untrusted array index read")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217064308.43559-6-pkshih@realtek.com
If failed to load a non-secure firmware with a secure chip, it only throws
a unclear message:
rtw89_8922ae 0000:03:00.0: parse fw header fail
To address this case simpler, add a message to point out this.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217064308.43559-5-pkshih@realtek.com
The sb_sel_ver is selection version for secure boot recorded in firmware
binary data, and its size is 4 and offset is 58 (not natural alignment).
Use get_unaligned_le32() to get this value safely. Find this by reviewing.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217064308.43559-3-pkshih@realtek.com
BT-coexistence configure WiFi TX time to share time slots with Bluetooth
devices. Since the format is different from WiFi 6 chips, add the new
format accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217063053.38936-3-pkshih@realtek.com
The agg_limit and txcnt_limit are used by BT-coexistence to reduce
WiFi TX time at once to share time with Bluetooth devices. Since
these registers address are different from WiFi 6 and 7 chips, define
them accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217063053.38936-2-pkshih@realtek.com
EHT MU PPDU contains user field of EHT-SIG field with STA-ID that
must match AID subfield in the Associate Response. Add a necessary
setting to prevent these from being inconsistent.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217061235.32031-1-pkshih@realtek.com
Since the vendor driver is claimed to measure 'tssi_alimk_time' of
'struct rtw89_tssi_info' in microseconds, adjust rtw8852b{t}-specific
'_tssi_alimentk()' to not mess the former with nanoseconds and print
both per-call and accumulated times. Compile tested only.
Fixes: 7f18a70d7b ("wifi: rtw89: 8852b: rfk: add TSSI")
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250213095006.1308810-1-dmantipov@yandex.ru
Major changes are listed below:
rtw88:
* preparation to support RTL8814AU
rtw89:
* switch using wiphy_lock and wiphy_work
* add BB context to manipulate two PHY as preparation of MLO
* improve BT-coexistence mechanism to play A2DP smoothly
* firmware file can contain regd table
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmep+PkACgkQjlvZYmhs
hd/Z9A/9EoGX8ntbOIVu10l5MMv8eOhcBxEBUbRerkl1gDriPeckh92BaOZTboQY
ajaUOfvegfQLql4V5TwgAcB9fYJBvdF60Unw0M+lUSVIvaZpQAFCWGnCbPM0jTq9
kg7ytE6Qc9lZ7crW2zo3ARgXYwPoGKS1PE8f2J3Hswu5XVgmU4NJ8xBNiuJWg7vX
U6eN0G23yUA/uC5aBb1z9kqh6Vwbs8R0V7gOyJGARkXOhBx9FakQ5pl+GuFN/f07
KNR8ZJTNderfODE1xgZ8wqAeVNljGQKXgUS8UymbHOdSVUbuYQvIT5KyVSw2XFMX
zBhgSypFP7z/IcrNLpql3gt8NRU17N1CG+JG9ciseiGeCKppxFaU0DYEVH3PFCnT
QmKsqwD6FG9/XjOPQE2wt5LrIEJwlvujkYGlfouKXQIQbDcurQsTQsDED0ToNluv
u9LEor34tQjncaPnSgWyW8R6DtELvAfOoTOPpXB0DhGGJas1sKJfasbE3EFLhKg3
kRr56jtAlp7W8r+HMHrDyy9Sdnk0c2cWCiN5SdGHayVUxjqjd06OnEr6M05JRkX+
Rh2C7hsREKH7iTwR0z1P2zIRh3E8+lx+nDj3SS/Scq7aQp8XDQyG6+LwhPuyXAzn
hmaXrRb8VRktSy5crETGbQLPCLkQZbslUe6p3GBUpDZPFXE2908=
=arTU
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2025-02-10-v2' of https://github.com/pkshih/rtw
Ping-Ke says:
====================
rtw-next patches for v6.15
Major changes are listed below:
rtw88:
* preparation to support RTL8814AU
rtw89:
* switch using wiphy_lock and wiphy_work
* add BB context to manipulate two PHY as preparation of MLO
* improve BT-coexistence mechanism to play A2DP smoothly
* firmware file can contain regd table
====================
Link: https://lore.kernel.org/linux-wireless/b65fae15-79bf-40fa-8acc-63d87ae35e19@RTEXMBS04.realtek.com.tw/
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Due to hardware design constraints, a reset handshake may be
necessary even when the firmware has already crashed, with
the dump descriptions indicating which parts should be done
before/after the handshake, if needed. Implement that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.9296e3113d42.Ifb32703fd06a644d08a86b7af1b990738e3c8134@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is a bit that tells the firmware to wait for the
PHY_CONFIGURATION_CMD before completing its init sequence.
Clarify this in the comment.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.097510347ae2.Ica00b4b30163a21bf993fa968dd406ee4023fc9e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We'll have devices that are EHT capable but don't support 320 MHz and
those devices look like the 320 MHz capable devices, but have distinct
subsystem ID.
We already had the same type of differentiation for HE devices that
support 160 MHz or not.
Enhance that mechanism and now the _IWL_DEV_INFO macro gets an
indication whether the bandwidth should be limited for that specific
device.
The subsystem ID gives a binary answer about the bandwidth limitation
and iwl_pci_find_dev_info() compares this to the list of _IWL_DEV_INFO
entries.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.1ba406c538a5.I6e24123f60a764aedfeaaac8768c26e136c320cf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Re-probing if we had 2 firmware crash within 3 minutes is really too
aggressive. Drastically reduce the threshold to 7 seconds.
After 7 seconds, a new firmware crash will be considered "new" and not
cause a PCI re-probe.
This allows to pass tests that cause a firmware crash every 10 seconds
and expect to see no impact on the traffic.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.38f912b047f4.I03f0c10ae9e7ecea639431f3e089b757cc8a4347@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As MLO link configuration is supported by mac80211, indicate
support for MLO link reconfiguration in station mode.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
----------------
depends on "wifi: ieee80211: Add some missing MLO related definitions"
Link: https://patch.msgid.link/20250205145347.92d19705d2b9.Id07fa3ebad6bc23ecf6e91868f67150ce70f47b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We're adding a new IWLMLD opmode for just BZ and later
devices. If that's enabled but IWLMVM isn't, the build
fails because 22000 family configs aren't built but BZ
and later refer to it. Rather than trying to make some
new file to build it in all cases, just copy the small
struct.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.1d6186c23bee.I3c61a6c9e0db3ba6eea4dac63e1547945ad01703@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Despite not being able to sustain the full 320 MHz throughput
even at MCS 9, enable 320 MHz on slow PCIe links. This may in
some cases result in frames being dropped (on the air) by the
firmware if they cannot be delivered to the host, but it can
still be better to use 320 MHz.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.1e5356a3b124.I1224023721aaeff8ebcaa47dff88613c7fd0533a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
During reprobe, the sw state is being destroyd, and so is the
connection. When the peer STA is being removed, the opmode sends a
command to flush the TXQs of the STA and uses iwl_trans_wait_txq_empty.
This one warns if the FW is not alive, but it really shouldn't if
there is a FW error - and return silently instead, just like we do when
sending a hcmd.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250205145347.76425b10e5a0.I3bf0de2eb090a8b94c4e36d93dd91df61fadb808@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Created a common function iwl_add_mcc_to_tas_block_list() to handle the
operations previously performed by iwl_mld_add_to_tas_block_list() and
iwl_mvm_add_to_tas_block_list(). moved this new function to regulatory.c
to better reflect its purpose and improve code organization.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.157d26fb7f02.I87e20e967835bc895be390daf1c6637e20b52aae@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Renamed iwl_mvm_eval_dsm_rfi() to iwl_rfi_is_enabled_in_bios() to better
reflect the function's operation. Additionally, moved the function to the
regulatory.c file for better organization. optimize local variable
usage in it.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205145347.b7ac9d05234e.Ieb623d7e8dca6bb6a5733682b31e4ff1e39373f0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we disassociate we may need to send a deauth frame.
Regardless of this decision, we need to flush the queues to drop all the
packets on the Tx queues.
The flow looks like this:
1) Flush packets waiting on the queues (drop=true)
2) Prepare Tx to send the deauth
3) Build the deauth header
4) send the deauth
5) Flush the deauth packet (drop=false)
6) Complete_tx
Step 3 and 4 are done in ieee80211_send_deauth_disassoc() and that
function must be called even if we decide not to send the deauth
frame because we need step 3 for cfg80211.
This means that if we want to send the deauth frame, we need all the
steps, but if we don't want to send the deauth frame we still want step
1 and 3.
Change the code to do that.
Also, prevent sending the deauth frame if we are in the middle of a CSA
with mode=1 in which case we won't be able to send the frame anyway.
This caused issues in iwlwifi at step 5 since the firmware wouldn't
send the frame and we'd be stuck flushing with drop=false.
Implement this in ieee80211_set_disassoc() which has many callers.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205110958.480bfea605e0.I91131eed942e49b9885d73f4180a3c9c26691c62@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This wiphy work is canceled when the iface is stopped,
and shouldn't be queued for a non-running iface.
If it happens to be queued for a non-running iface (due to a bug)
it can cause a corruption of wiphy_work_list when ieee80211_setup_sdata
is called. Make sure to cancel it in this case and warn on.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250205110958.99204c767c10.I84ce27a239059f6009cee197b252549a11426046@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With the previous patch to no longer access deflink for aggregation
it seems we no longer access the deflink for MLO stations (MLDs) so
we can allow removing the assoc link.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205110958.05bc2175cea2.I8f62609a682fdf3f703872d0fce63ab6a4780a7e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a station has connected with MLO (as indicated by valid_links
being non-zero, even if that may have just a single bit set), it
necessarily supports EHT/aggregation, so we don't need to check
the deflink for those cases.
Add conditions so we can support removing the link it/we used to
associate on.
Note that we still use the statistics in the deflink, but that's
a whole different story we will need to address separately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250205110958.daf2a9e367f2.Id2c2dfbbe7451cc900ed88c5a81b33c55b4ab1cf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
