The existing flow is doing BB pre-init before downloading BB MCU firmware,
because existing chip RTL8922A has BB MCU. However, the coming chips don't
have this, and BB pre-init configuring registers can affect downloading
WiFi-CPU firmware. Therefore, calling BB pre-init afterward for new coming
chips without BB MCU.
For existing WiFi 6 chips, no BB pre-init. For RTL8922A, don't change
the logic.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-5-pkshih@realtek.com
Driver needs to initialize registers before downloading firmware, so
move pre-init part (power on) from original rtw89_mac_init(). The
consequence patches will add more pre-init codes before downloading
firmware.
Since rtw89_phy_init_bb_afe() is used by coming RTL8922D, don't change
logic at all for existing chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-4-pkshih@realtek.com
In the wpa_supplicant rekey flow, it sends an EAPOL packet 4/4 through
nl80211_tx_control_port() and triggers wake_tx_queue() in the driver.
Then, it sends nl80211_new_key() to configure a new key in mac80211.
However, in wake_tx_queue(), a workqueue is used to process the TX packet,
which might cause the driver to process the EAPOL packet later than
nl80211_new_key(). This results in the EAPOL packet 4/4 being transmitted
with the new key and IV, causing it to be dropped by the AP. Therefore,
needs to flush TX queue before deleting the old key to ensure that the
EAPOL 4/4 packet is transmitted using the old key.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-2-pkshih@realtek.com
To be able to capture and inject packets in monitor mode, do RF calibration
once setting certain channel. Since calibration costs time, do not change
behavior of normal usage, which do calibration only when starting as AP
or going to connect AP.
Since driver declares IEEE80211_HW_WANT_MONITOR_VIF, the pure monitor vif
must be only one when adding interface with type NL80211_IFTYPE_MONITOR.
Otherwise, monitor vif must be NULL.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-8-pkshih@realtek.com
Coverity reported a potential out-of-bounds access when 'bw' exceeds the
valid range for the specified band. Add a helper `rtw89_bw_is_valid()`
to check bandwidth validity for each band before accessing limit tables.
Addresses-Coverity-ID: 1598844 ("Out-of-bounds access")
Addresses-Coverity-ID: 1598896 ("Out-of-bounds access")
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-6-pkshih@realtek.com
The rules to diagnose MAC have a common header, and a cmd field is used
to know the exact command and its format. The rules with the same tuple of
fields {sheet, seq} can be seen as a set of compound rules, which treat
it as positive rule if just one of the rules is positive.
Take EQUALV rules as example, if value of {addr, mask} is equal to
predefined value as field val, a rule is positive. Fields addr_name_offset
and msg_offset are offsets related to textual messages for human readable.
Format of common rule header (8 bytes)
+-------+-----+--------+-----------+-----+---------+
| sheet | cmd | seq[2] | io / band | len | rsvd[2] |
+-------+-----+--------+-----------+-----+---------+
Format of rule command is EQUALV (equal value) (24 bytes):
+------+------------------+------+-----+------------+---------+
| addr | addr_name_offset | mask | val | msg_offset | rsvd[4] |
+------+------------------+------+-----+------------+---------+
Format of message:
+-----+----------+
| len | string[] |
+-----+----------+
An example of output:
Plain(Ignore)/Rules/Positive: 115(4)/86/81
Where, Plain is total rules written in firmware element.
Ignore is the ignored rules, such as USB IO, but current is PCIE.
Rules is number of set of compound rules.
Positive is number of positive Rules.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-4-pkshih@realtek.com
The firmware element ID 28 is a set of rules to diagnose if MAC get
abnormal. The latter patch will use these rules via debugfs to know
the status.
The element contains rules with their textual messages shown as below:
+------------------------------------+
| |
| +-----------+ |
| | rule_size |-------|----------+
+----------------+-----------+-------+ -- |
| rule[0] | \ |
| rule[1] | | <---+
| : | /
+------------------------------------+ --
| msg[0] msg[1] | each msg has variable length
| msg[2] msg[3] ... | (with address align 2)
| ... |
+------------------------------------+
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-3-pkshih@realtek.com
TX wait skbs need to be completed when they are done. PCIe part does this
inside rtw89_pci_tx_status() during RPP processing. Other HCIs use a
mechanism based on C2H firmware messages.
Store TX wait skbs inside TX report queue so that it'll be possible to
identify completed items inside the C2H handler. Try to do this as
similar to PCIe path as possible. When the corresponding TX wait skb is
found inside TX report queue, unlink it from there and call
rtw89_core_tx_wait_complete() to mark the completion.
If the callee waiting for the completion has already timed out, the TX
wait skb is placed into TX wait list (like PCIe part does).
It's important that during HCI reset all pending TX wait frames should be
completed inside hci.ops->reset method before calling
rtw89_tx_wait_list_clear().
Found by Linux Verification Center (linuxtesting.org).
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251104135720.321110-11-pchelkin@ispras.ru
Frames flagged with IEEE80211_TX_CTL_REQ_TX_STATUS mean the driver has to
report to mac80211 stack whether AP sent ACK for the null frame/probe
request or not. It's not implemented in USB part of the driver yet.
PCIe HCI has its own way of getting TX status incorporated into RPP
feature, and it's always enabled there. Other HCIs need a different
scheme based on processing C2H messages.
Thus define a .tx_rpt_enabled flag indicating which HCIs need to enable a
TX report feature. Currently it is USB only.
Toggle a bit in the TX descriptor and place flagged skbs in a fix-sized
queue to wait for a message from the firmware. Firmware maintains a 4-bit
sequence number for required frames hence the queue can contain just 16
elements simultaneously. That's enough for normal driver / firmware
communication. If the firmware crashes for any reason and doesn't provide
TX reports in time, driver will handle this and report the obsolete frames
as dropped.
rtw89 also has a new feature providing a TX report for each transmission
attempt. Ignore a failed TX status reported by the firmware until retry
limit is reached or successful status appears. When there is no success
and the retry limit is reached, report the frame up to the wireless stack
as failed eventually.
HCI reset should stop all pending TX activity so forcefully flush the
queue there.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251104135720.321110-9-pchelkin@ispras.ru
During HCI reset all pending TX URBs should be canceled. Use anchor to
keep track of them and have an ability to cancel them synchronously.
Note however that canceling RX URBs can't be done here in
rtw89_usb_ops_reset() as it breaks driver initialization.
Found by Linux Verification Center (linuxtesting.org).
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251104135720.321110-8-pchelkin@ispras.ru
rtw89 has several ways of handling TX status report events. The first one
is based on RPP feature which is used by PCIe HCI. The other one depends
on firmware sending a corresponding C2H message, quite similar to what
rtw88 has.
Toggle a bit in the TX descriptor to indicate to the firmware that TX
report for the frame is expected. This will allow handling TX wait skbs
and the ones flagged with IEEE80211_TX_CTL_REQ_TX_STATUS correctly.
Do the bulk of the patch according to the vendor driver for RTL8851BU.
However, there are slight differences in C2H message format between
different types of chips. RTL885xB ones follow format V0. RTL8852C has
format V1, and RTL8922AU has format V2.
Found by Linux Verification Center (linuxtesting.org).
Suggested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251104135720.321110-6-pchelkin@ispras.ru
Pass TX status value directly into rtw89_core_tx_wait_complete(). This
will make it a bit in sync with further patches and will give flexibility
in future work. Also use scope based RCU locking which simplifies the
code of the function.
Found by Linux Verification Center (linuxtesting.org).
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251104135720.321110-5-pchelkin@ispras.ru
When there is an attempt to write data and RTW89_FLAG_UNPLUGGED is set,
this means device is disconnected and no urb is submitted. Return
appropriate error code to the caller to properly free the allocated
resources.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 2135c28be6 ("wifi: rtw89: Add usb.{c,h}")
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251104135720.321110-3-pchelkin@ispras.ru
There are a few differences in the power on/off functions between PCIE
and USB. The changes in the power off function in particular are needed
for the RTL8832CU to be able to power on again after it's powered off.
While the RTL8832CU appears to work without the changes in the power on
function, it's probably best to implement them, in case they are needed
in some situations.
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/598dec66-b5cc-435a-bcf6-fa66577f8cfc@gmail.com
RTL8852AU, RTL8852CU, and RTL8922AU will need a different TX channel
to bulk out endpoint mapping, so create a new struct rtw89_usb_info
and move the mapping there. Initialise it in each chip's driver.
Struct rtw89_usb_info will also hold some registers which are located
at different offsets in RTL8852CU compared to the other wifi 6 chips.
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/de11cfae-1dc0-4514-95b2-02b1bbfa92be@gmail.com
Reduce scan time for all supported channels from 4.4s to 3.5s.
If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan request, only scan PSC
channels and the channels from the RNR element found on the 2.4/5 GHz
channels. When firmware support parsing RNR element from received beacon
or probe response, offload the decision about non-PSC channels to firmware.
Driver do not need to fill non-PSC channels to scan list. If
NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set, scan all supported channels.
Signed-off-by: Jui-Peng Tsai <emma_tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251021133402.15467-9-pkshih@realtek.com
Somehow power-save related functions get failure, such as failed to
send null packet, or no response form firmware, and then WiFi will
become unstable. Trigger SER function actively to reset firmware/driver
to recover from abnormal states, including
- firmware failed to ACK for entering PS mode
- firmware failed to ACK for leaving PS mode
- check PS H2C command received by firmware fail
- failed to leave PS state
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251021133402.15467-8-pkshih@realtek.com
To switch link, FW needs H2C commands to indicate which link is on or off.
Originally, these H2C commands are considered only when the link switching
is initiated by driver. But, in some cases, e.g. ml_reconf or TTLM, link
switching would be initiated by stack. Hence, plan these H2C commands into
ieee80211_ops.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251021133402.15467-4-pkshih@realtek.com
