| Age | Commit message (Collapse) | Author |
|---|
|
Pink-Ke Shih says:
==================
rtw-next patches for v7.4
Mainly, continue to develop RTL8922DE with many patches. Some random
cleanups and fixes. The major changes are listed below:
rtw88:
- support RTL8723BS (remove staging rtl8723bs by the way)
- add SDIO TX back-pressure to improve performance
rtw89:
- add P2P_DEVICE declaration
- many BT-coexistence update for RTL8922D
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Now we have cfg80211_mutex everywhere along with wiphy mutex
for per-device bits, so don't need RTNL any more. Remove it
from the regulatory code.
Also, wiphy_apply_custom_regulatory() no longer needs the RTNL,
and get_wiphy_regdom() can no longer rely on it.
Link: https://patch.msgid.link/20261006120655.df1d3d28cfa2.I637dbd328886b52bed511fb798172a2d57521263@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This will soon be required, because there won't be the
RTNL to protect everything. Use RCU for freq_reg_info().
Link: https://patch.msgid.link/20261006120655.2faed090a837.I556a1b30d7d7fee64edeeefa26996d62be14cfca@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The RTL8922AU holds received frames for up to a millisecond before
handing them to the host, a value carried over from the RTL8852CU.
On USB 3 that adds up to a millisecond of round trip, and under load
at 160 MHz the access point drops to lower rates and download suffers.
Shorten the hold on USB 3 only. On USB 2 the bus is the limit, and a
slow host needs the long hold to keep up.
RTL8922AU on USB 3 at 160 MHz, power save off for the round trip:
x86, 6 GHz x86, 5 GHz Pi 5, 6 GHz
before after before after before after
TCP down, 1 flow 613 1002 579 948 587 1010 Mbps
TCP down, 8 flows 656 1187 629 1080 605 1122 Mbps
round trip 2.33 1.29 2.25 1.18 1.42 0.84 ms
busiest core, UDP 200M 8.4 12.8 8.3 12.9 2.1 3.3 %
RTL8922AU on USB 2, Raspberry Pi 1 B+ at 5 GHz, 80 MHz:
long hold short hold
TCP up, 1 flow 102.3 87.7 Mbps
CPU, UDP 20M 50.5 77.4 %
loss, UDP 50M 3.8 85.7 %
Fixes: 32cee8a9bb66 ("wifi: rtw89: usb: Enable RX aggregation for RTL8922AU")
Reported-by: Nick Morrow <morrownr@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261007210958.56528-1-lucid_duck@justthetip.ca
|
|
__rtw89_wow_parse_akm() computes a pointer to the IE area from an
association request frame:
ies = mgmt->u.assoc_req.variable;
but then passes skb->len as the IE data length to cfg80211_find_ie().
Since skb->len covers the entire frame including the 28-byte management
header and fixed fields, cfg80211_find_ie() may read past the end of the
actual IE data.
Fix by computing the correct IE data length as skb->len minus the
header offset, and validating the minimum frame length before parsing.
Fixes: 92790c4e50d2 ("wifi: rtw89: wow: parsing Auth Key Management from associate request")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261007161721.261452-3-tristmd@gmail.com
|
|
RTL8852BE-VS (PCI ID 10ec:b85b, RFE type 41) has only one spatial stream
and likely one physical antenna, but the firmware reports two antennas.
This results in the driver configuring the wrong RF path, which leads to
very poor reception. Users complain that 5 GHz networks are not visible.
Hardcode the number of antennas for this RFE type to one, and the
correct RF path for the Bluetooth coexistence code. This is what the
vendor driver does.
Closes: https://lore.kernel.org/linux-wireless/10543730.tdPhlSkOF2@topolinux/
Closes: https://github.com/morrownr/rtw89/issues/128
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/c6f85442-dd1e-4971-943a-31bfb54eb0ed@gmail.com
|
|
Now that the chip support, firmware interface, coexistence, power
management and the SDIO transfer and association paths are all in place,
add the Kconfig symbols and Makefile rules that build the RTL8723B chip
module and the RTL8723BS SDIO front end.
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-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/20261006130701.120460-8-luka.gejak@linux.dev
|
|
Add the SDIO module for the RTL8723BS, the SDIO variant of the
RTL8723B. It binds the Realtek SDIO device ids to the shared rtw88 SDIO
probe and points it at the RTL8723B chip information.
The device id table carries the same six ids the staging rtl8723bs
driver binds to this chip, so the staging driver can be dropped without
losing hardware support. I only have the 0xb723 variant to test with.
The other five are included for parity with staging, which has carried
them for years, rather than being left behind.
The RTL8723B chip support is based on the initial work by
Michael Straube <straube.linux@gmail.com>.
Link: https://github.com/mistraube/rtw88/tree/rtl8723bs
Co-developed-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-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/20261006130701.120460-7-luka.gejak@linux.dev
|
|
Add the Realtek RTL8723B 802.11n chip driver: the chip operations, the
power sequences, the efuse layout, the RF and IQ calibration, and the
chip specific coexistence handling.
The RTL8723B chip support is based on the initial work by
Michael Straube <straube.linux@gmail.com>.
Link: https://github.com/mistraube/rtw88/tree/rtl8723bs
Co-developed-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-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/20261006130701.120460-6-luka.gejak@linux.dev
|
|
The RTL8723B driver needs the receive PHY status layout, the SDIO
aggregation burst fields and four baseband registers, which currently
live in rtw8703b.h. Move them to rtw8723x.h, the header for the
definitions shared within the family, and rename struct phy_status_8703b
to struct phy_status_8723x. The layout is called phy_status_rpt_8192cd in
the vendor driver. This is not a logical change.
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261006130701.120460-5-luka.gejak@linux.dev
|
|
Add the MAC register table and the baseband, RF and AGC parameter tables
for the RTL8723B, and the transmit power limit and power by rate tables,
in the layout the shared rtw88 phy code expects.
The RTL8723B chip support is based on the initial work by
Michael Straube <straube.linux@gmail.com>.
Link: https://github.com/mistraube/rtw88/tree/rtl8723bs
Co-developed-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-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/20261006130701.120460-4-luka.gejak@linux.dev
|
|
Add the register offsets and bit definitions the RTL8723B driver uses,
including the power and system function bits, the BT antenna and efuse
control registers, the packet lifetime and MAC ID drop registers, the
FPGA0 HSSI and RF switch control registers, and the RFE antenna path
registers.
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-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/20261006130701.120460-3-luka.gejak@linux.dev
|
|
The CCK power detect setter in rtw88xxa.c programs values that are not
specific to that chip family. The RTL8723B wants the same setter, but
pulling in the whole rtw88_88xxa module for one helper is not worth it.
Move it to phy.c as rtw_phy_cck_pd_set(), where the rest of the CCK power
detect code and the level enum already live. rtw8812a and rtw8821a call
the core version, so rtw88xxa.c no longer provides it. No logical
changes have been made at all.
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-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/20261006130701.120460-2-luka.gejak@linux.dev
|
|
The firmware version 0.35.119.0 changes hw_scan format, which isn't
compatible with old driver. The BT-coexistence also implements much
features in firmware side until 0.35.119.3, which needs driver side
implementation accordingly. The REGD table included in firmware
file add NZ/BR/AR countries. Increase format to 1 to prevent old driver
load the new firmware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261007011057.12125-4-pkshih@realtek.com
|
|
Add NZ (New Zealand), BR (Brazil) and Add AR (Argentina) into Realtek
regulatory enum. Some chipsets may need individual TX power settings
for them.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261007011057.12125-3-pkshih@realtek.com
|
|
Update 0.35.119.3 Wi-Fi firmware support. Fix dual BT, dual MAC,
MLO mechanism binding control not working issue. Fix AX/BE serial
chips logic mixing error.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261007011057.12125-2-pkshih@realtek.com
|
|
The buffer full check used >=, which rejects a command that would
exactly fill the buffer even though it still fits. Change to > so a
command is only rejected when it would actually overflow hbuf.
Also drop the duplicate BTC_H2C_MAXLENC definition in core.h and keep
BTC_H2C_MAXLEN from coex.h as the single source of truth for the H2C
macro buffer size.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261005053855.17740-1-pkshih@realtek.com
|
|
_update_wl_mlo_info() derives path_rf_band, link_mode, dbcc_en and
other per-RF-path fields from the current MLO link_status, but never
wrote mlo_info->rf_combination in any of the three link_status cases.
The field stayed at its zero-initialized value, which aliases
BTC_MLO_RF_2_PLUS_0.
_set_bind_info() and _set_coex_binding() both branch on
rf_combination to decide how to bind WL RF-paths to BT devices for
1+1, 2+2, 2+0 and 0+2 MLO combinations. With the field always zero,
those branches silently treated every MLO combination as 2+0,
producing an incorrect WL/BT binding whenever the real combination
was 1+1, 2+2 or 0+2.
Set rf_combination to the matching BTC_MLO_RF_* value in each of the
2+0, 0+2 and 1+1/2+2 branches so the binding logic sees the actual
RF combination.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-16-pkshih@realtek.com
|
|
Nothing drives the BTG control that turns the BT TX/RX on and off, so the
BT keeps transmitting and receiving even where COEX already knows it is
not in use, and WL takes interference it does not have to.
Program it from the BT enable state coex already maintains, which is the
same value reported to the firmware, so a driver-side write and a
firmware-side one always agree. This matters for the BT-only case, where
that state is forced to enable both BT while the per-BT enable may still
be clear.
That report was not actually reaching the firmware. The control
information is sent only when it differs from what was sent last, but
the comparison is inverted, so an unchanged run sends a redundant
command while a real change is dropped. Drop the inversion, so the
state programmed here is the state the firmware is told about.
Each BT keeps its own shadow of what was programmed and of whether that
is trustworthy, rather than writing on a change of the enable state. A
change is a one-shot edge, so an RF write the lower layer refuses would
never be retried, and an offloaded write can be refused for reasons coex
cannot see. The shadow is dropped on init and on a radio-state change
since the RF may have been re-initialized, and compared on every run so
that a redundant write is suppressed without losing the retry. Skip the
whole thing while the RF is off, and on chips with a single BT, which do
not drive this control from the driver side.
Report the state and the shadow in the coex mechanism-status dump.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-15-pkshih@realtek.com
|
|
The WiFi BE serials chips could disable BT TX/RX by BTG control, with this
control logic, WiFi could lower down the interference signal from BT.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-14-pkshih@realtek.com
|
|
Two unrelated enumerations describe a BT antenna switch type. The one
the RTL8922D antenna configuration uses numbers the absent switch as
zero and the internal switch as one, while the older one numbers the
internal switch as zero. The shared 2-antenna case picked the internal
value from the older enumeration, so it stored zero and claimed no
switch at all.
A BT whose switch type says there is no switch is treated as not sharing
an antenna with the WL RF-path that the other RF-path shares with it,
which drops the cross-talk entry for that path. Store the value from the
enumeration this field is read with. The 1-antenna and 3-antenna cases
in the same function already do.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-13-pkshih@realtek.com
|
|
The WL/BT space-interaction map that decides whether a WL RF-path and a
BT take a TDD or an FDD action is built from the antenna-division map
with the cross-talk map. A WL RF-path that physically shares its
antenna with a BT must be marked in the antenna-division map, otherwise
it is only ever marked interacting when the measured WL RSSI happens to
fall below the BT Tx interference threshold, and a shared-antenna design
with a strong WL signal gets bound to FDD where it has to coexist in
time instead.
Chips with a single BT never filled that map, so fill it from the RFE
type that the antenna configuration is already derived from: mark the
one WL RF-path that carries the BTG circuit as sharing with the only BT
whenever the antenna type is shared, and leave the map clear for the
dedicated-antenna RFE types where the BT has an antenna of its own. The
second-BT and external-coexistence columns stay clear because these
designs have neither.
This is driver-internal state only. The coex init information these
chips send to firmware has no antenna-map field, so what reaches the
firmware is unchanged.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-12-pkshih@realtek.com
|
|
A BT TX power report identifies which BT device came from, in bit 7
of its second byte, whether it describes that device's 2.4 GHz
or 5/6 GHz link. The handler ignored both and always wrote the first
BT device's 2.4 GHz link info.
On a chip with two BT devices or with 5/6 GHz BT support, the reported
power therefore never reached the second device or the 5/6 GHz link.
The TDD/FDD switch threshold reads exactly those fields when the WL
link is not on 2.4 GHz or when it scores the second BT, so on those
paths it kept comparing against the reset default instead of what BT
actually transmits at.
Select the device from the report's own index and the link from its
band bit, the same way the other BT mailbox reports already do.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-11-pkshih@realtek.com
|
|
The RF band that TDD and FDD bind to is picked by scoring each BT
link's weight against the WL/BT band-overlap map. That map is built
from connected WL links, so while WL is running RFK on a band it has
not associated on yet, neither band scores and the binding ends up
empty. Coexistence then treats the chip as having no WL/BT band
overlap at all and leaves RFK unprotected against a BT device already
transmitting on that same band, which can corrupt the calibration
result.
Force the score of the band being calibrated up to the binding
threshold when any BT is on an overlapping band, so the RFK band
binds for as long as the calibration runs.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-10-pkshih@realtek.com
|
|
The TDD/FDD switch threshold is derived as the WL RSSI at which a BT
device's TX power, after antenna isolation, starts to interfere:
110 + bt_pin - ant_iso - sir_thres, in RSSI percent. Before the first
BT TX power report arrives, and on any link whose report never
arrives, bt_pin falls back to the BR/LE defaults, so those defaults
decide where coexistence flips between TDD and FDD.
Both defaults were 4 dBm, which places the threshold about 6 dB below
what the BT side actually transmits at, so the driver stays in FDD
well past the point where BT TX already interferes with WL RX. Raise
both to 10 dBm, which matches the BT TX power these designs report
once their first query completes.
The 8922A ext-SOC path already used a separate 10 dBm define for the
same reason; drop it now that the common default carries that value.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-9-pkshih@realtek.com
|
|
Firmware 0.35.119.3 moves both RTL8922A and RTL8922D to coex H2C
role-info version 11 and outsrc-set-info version 7. Add top
ver_defs entries for both chips with the new fwlrole and fcxosi
values; all other scope versions are unchanged from the previous
firmware.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-8-pkshih@realtek.com
|
|
When a BT CIS (LE-audio) link exists on a dual-BT, shared-antenna
chip, limiting WL to 1SS on the RF-path that is isolated from that
link protects WL Rx from the CIS traffic without a full freerun
fallback. Add _set_trx_nss() to compute whether that 1SS limit
should apply, which path it should apply to, and what stream count
and path the WL TRX should fall back to when it does not, gated on
a chip-reported MIMO-PS capability flag and limited to Lenovo
designs or dual-BT chips to match the hardware this has been
validated on. The result also re-arms the limit once after a device
exits low-power state, since LPS can clear the BB/RF setup the
previous decision put in place.
The RTL8922D 3-antenna shared configuration also claimed that
capability, but it has no WL path shared with BT to power down, so
the limit there would cost a stream without buying any isolation.
Measurement on that configuration confirms it, so stop reporting
the capability for it and leave the 2-antenna configuration as the
only one that does.
There is currently no driver API to apply the computed stream/path
decision to the BB and RF, so the function stops right after
printing the decision for debug and before it would otherwise update
dm->wl_trx_nss, recompute the cross-talk maps, or call into set_rfe().
Those steps follow once that HW-apply API exists.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-7-pkshih@realtek.com
|
|
The TDD/FDD binding logic consumed dm->sit_xmap and dm->xtk_xmap to
decide whether a WL RF-path and a BT device need TDD or FDD
coexistence, but nothing in the driver ever wrote those two maps, so
they stayed all-zero and the binding logic silently fell back to
whatever that implied. Add _update_wl_rssi_status() to track the
minimum WL RSSI across all connected roles and HW-bands and turn it
into a per-BT interference state by comparing it against each BT's
Tx power minus antenna isolation, and _update_sdm_map() to turn that
state plus the existing antenna-sharing map into the cross-talk and
space-interaction maps the binding logic expects.
Call _update_wl_rssi_status() from the per-station notify path where
RSSI is refreshed, and recompute the maps whenever it reports a
change or whenever the BT scoreboard flips the dedicated TRX-active
bit that forces TDD regardless of RSSI. _update_sdm_map() also runs
once during coex init so the maps are populated before the first
coex cycle, and _set_coex_binding() now derives dm->fit_used_path and
a per-path dm->fit_map alongside the existing fit_xmap use, which a
later change will need once it introduces 1SS Rx-path limiting.
Whether the WL path under a 1SS RX limit still co-receives with a BT
device also depends on traffic direction: the limit only confines
RX, so the cross-talk map that feeds the TDD/FDD binding is derived
differently for downlink than for uplink. Also recompute the maps
when the per-station notify path latches a traffic direction flip,
so a downlink-to-uplink switch with a steady RSSI does not leave the
binding running on the previous direction's map until some later
event happens to refresh it.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-6-pkshih@realtek.com
|
|
The outsrc-set-info H2C used its last reserved byte for nothing. A
newer firmware version reuses that byte to carry whether BT shares
an SPDT switch with WL at the BB level, which the firmware needs to
pick the right RF constraint. Add a v7 variant of the struct with
the top bit of that byte named is_spdt_bb and the rest kept
reserved, a matching H2C sender, and dispatch fcxosi == 7 to it.
Also widen the gnt_set_be branch in the GNT H2C sender to cover
fcxosi == 7, since it shares the same GNT layout as v6, and add the
paired W2B/B2W scoreboard bits that let WL request and BT acknowledge
the LNA-backoff table for this fcxosi version.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-5-pkshih@realtek.com
|
|
The WL status debug dump only printed role, channel and link-mode
state for HW-band 0, even on chips where MLO support means both
bands carry an independent connection. Add an [MLO] line that
prints the operating mode, channel type, RF band and P2P-exist
state for each HW-band side by side, gated on the chip actually
supporting MLO so single-band chips keep the shorter dump.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-4-pkshih@realtek.com
|
|
The role info fields that distinguish HW-band 0 from HW-band 1 were
kept as separate scalar members with a "_hb1" suffix for the second
band, which forced every caller to branch on hw_band and duplicate
the same logic for each member. Convert link_mode, p2p_exist and
role_map in the role info, plus is_5g_hi_ch, go_client_exist,
noa_exist and bg_mode in the WL info, into RTW89_MAC_NUM-indexed
arrays so a single hw_band index addresses both bands.
This lets _update_wl_link_mode(), _update_wl_mlo_info(),
_modify_role_link_mode() and _update_wl_info() drop their
hw_band == RTW89_PHY_1 branches in favor of direct array indexing,
and removes the duplicated per-band assignments at every call site.
The firmware-facing H2C formats are unchanged; only the internal
representation moved from named pairs to an array. Add v11 of the
role info H2C structure and its sender so a later firmware version
bump has a destination to send to. And it should not sharing layout
with the existing v10 structure.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-3-pkshih@realtek.com
|
|
dm->tdd_bind.rf_band holds a bitmask built from BIT(BTC_BT_B2G) and
BIT(BTC_BT_B5G), but _set_rf_trx_para() compared it against the raw
band enum values RTW89_BAND_5G and RTW89_BAND_2G instead of their
BIT() form. Every other site in this file that reads tdd_bind.rf_band
wraps the enum with BIT() before comparing.
Because RTW89_BAND_5G equals 1 and BIT(BTC_BT_B2G) also equals 1, a
Wi-Fi/Bluetooth coexistence session bound to the 2.4 GHz band was
misclassified as BTC_WLINK_V0_5G. This incorrectly skipped the RF
Tx/Rx parameter adjustment for 2.4 GHz STA traffic and kept clearing
wl_stb_chg to 0, so chip->ops->btc_wl_s1_standby() never re-enabled
the Wi-Fi standby workaround for the Bluetooth Tx-to-Rx GNT switch on
RTL8852C, degrading Wi-Fi performance while coexisting with Bluetooth
on 2.4 GHz.
Compare rf_band against BIT(RTW89_BAND_5G) and BIT(RTW89_BAND_2G) to
match its actual bitmask representation.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-2-pkshih@realtek.com
|
|
The 'imply' in Kconfig to weakly and implicitly select dependencies is
discouraged. Remove them to simply logic.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/linux-wireless/7cdc36a9-aadd-4636-8a29-847d89638c8d@app.fastmail.com/T/#t
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261002065058.13535-1-pkshih@realtek.com
|
|
Wrap the register writes of rtw89_phy_init_rf_nctl() with
rtw89_io_pack/unpack so they are batched into single bus transactions,
reducing API execution time.
8852C USB2.0 AMD B450 initialization time:
rtw89_phy_init_rf_nctl 5355 ms -> 10 ms
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-7-pkshih@realtek.com
|
|
Type 15 gain-table records now encode the FEM index in bits 31:16 and
the gain-table version in bits 15:0.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-6-pkshih@realtek.com
|
|
To cancel some 6 GHz probe cases, it just depends on if a skb matches
some corresponding conditions. Because the decision has nothing to do
with vif, it's redundant to do the cancellation per vif, i.e., single
case will be cancelled multiple times. So, move it out of iteration.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-5-pkshih@realtek.com
|
|
In rx path, there are skb of Wi-Fi and skb of PPDU. However, skb_ppdu was
used in some places for Wi-Fi skb. It was a bit confused. So, refine the
naming as follow-up. Call skb for skb of Wi-Fi, and call skb_ppdu for skb
of PPDU. Besides, call desc_ppdu for rx_desc_info of PPDU.
(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/20260930064524.39403-4-pkshih@realtek.com
|
|
The "diliver" should be "deliver", so fix them.
(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/20260930064524.39403-3-pkshih@realtek.com
|
|
When entering FWIPS, also send the H2C command related to MLO info, the
same as in LPS. Otherwise, the firmware cannot get enough information.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-2-pkshih@realtek.com
|
|
Many USB and SDIO devices can't report TX status within 500 ms, and
extending to 2500 ms as tested USB/SDIO devices can fix the problem [1].
To avoid adding chip ID one by one, and this change looks harmless.
Keep PCIE using short timeout, and others use long timeout.
[1] https://lore.kernel.org/linux-wireless/20260921165343.8131-1-pepe.schlehofer@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Luka Gejak <luka.gejak@linux.dev>
Tested-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://patch.msgid.link/20260924004637.9958-1-pkshih@realtek.com
|
|
Check the key index reported by firmware before updating the GTK RX IV
information in the AOAC report.
The key index is obtained from the firmware C2H register and is used
to select the GTK RX IV entry. Make sure the reported index is within
the available GTK RX IV entries before processing the report.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923072741.54118-4-pkshih@realtek.com
|
|
The AOAC report C2H event contains fixed-size fields including GTK
and IGTK. The received C2H skb may contain less data than the expected
AOAC report size.
Check the skb length before processing the AOAC report to ensure the
complete report is available.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923072741.54118-3-pkshih@realtek.com
|
|
There is a map used to record the associated links by MAC ID, but L2 SER
(system error recovery) will invoke ieee80211_restart_hw to reset things.
After ieee80211_restart_hw, the associated links will re-configure, but
each associated link might not use the same MAC ID as the original one.
If an associated link doesn't and the old MAC ID is not re-used, the map
keeps the old pair of old MAC ID and it. And then, if somehow HW fills a
wrong MAC ID, e.g. the old MAC ID above, in RX, SW will still obtain the
associated link. Once the one is really disconnected, the memory will be
freed and this case will cause problems.
So, reset entire map of associated links before ieee80211_restart_hw call.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923072741.54118-2-pkshih@realtek.com
|
|
On USB, the register writes in coex init cannot be fully batched
into a single H2C because the write32 IO offload only carries
MASKDWORD, i.e. a full-dword overwrite. Read-modify-write helpers
derive the new value from a driver-side read that cannot observe
other writes still queued in the same pack region, so packing a
same-register sequence would drop bits. mac_coex_init_v1() and
btc_set_wl_pri() were thus left outside the pack region and issued
as separate H2C commands, costing hundreds of ms.
Add write8_mask/write16_mask/write32_mask to the IO ops. For the raw
IO path, these ops are implemented as direct read-modify-write on the
hardware. For the firmware offload path, they forward the field mask
to the FW so it can perform the read-modify-write server-side,
removing the dependency on a driver-side read of a register whose
new value may still be queued.
Extract the raw read-modify-write bodies of write8_set, write16_set,
write32_set, write8_clr, write16_clr, write32_clr, write8_mask,
write16_mask, and write32_mask into rtw89_raw_write*() helpers,
grouping raw_* variants before the io-dispatching thin wrappers.
Replace the original functions with thin wrappers that dispatch
through rtwdev->io, removing the inline capability checks. With that
in place, extend the 8852c PTA init pack region to cover
mac_coex_init_v1() and btc_set_wl_pri().
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-8-pkshih@realtek.com
|
|
On USB, 8852C is the only chip with .support_fw_cmd_ofld set, which
routes register writes through the FW command offload path via the
transparent io_ops indirection. The coex layer never entered an
rtw89_io_pack() region, so its register writes were always issued
individually instead of being batched to the firmware.
Wrap the RF LUT and GNT write sequences in rtw8852c_btc_init_cfg(),
rtw8852c_btc_wl_s1_standby() and rtw8852c_set_wl_lna2() with
rtw89_io_pack()/rtw89_io_unpack() so that on USB these writes are
enqueued and flushed as a single FW command batch. On PCIe the pack
region is a no-op and raw MMIO proceeds unchanged.
Only write_rf partial-mask, write-only sequences are offloaded, for
which the firmware performs the read-modify-write. Driver-side
same-register read-modify-write helpers and BB phy_write32 flows are
kept outside the pack region to avoid the offload full-dword
overwrite hazard.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-7-pkshih@realtek.com
|
|
To make IO wrappers of pack/unpack/udely/mdely can intuitively call
the loaded IO ops as others do, add corresponding instances for them.
And, expect all rtw89_io_ops initializers should assign all members.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-6-pkshih@realtek.com
|
|
The scoreboard update function was changed to always read from
scbd_c2h, which is populated only by BTF_EVNT_BT_SCBD C2H events from
the BT firmware. This caused two problems.
First, calling _update_bt_scbd at the NTFY_INIT notification with
scbd_c2h still zero would set bt->enable.now to 0, overwriting the
bt-on assumption that _ntfy_init_coex establishes for all chips. Remove
the NTFY_INIT call to preserve that default.
Second, chips whose BT firmware does not send BTF_EVNT_BT_SCBD events
have scbd_c2h stuck at zero indefinitely, making scoreboard updates
non-functional. Restore a hardware register read path by adding
_read_scbd() and an is_c2h flag to _update_bt_scbd. The
NTFY_RADIO_STATE path passes is_c2h=false to read the hardware
scoreboard register directly, ensuring correct BT state even without
C2H support. Pass BTC_ALL_BT so both BT devices are refreshed on
dual-BT chips.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-5-pkshih@realtek.com
|
|
Add a new entry in rtw89_btc_ver_defs for RTL8852C firmware version
0.27.130.1, which introduces fcxbtcrpt=205. The new entry activates
the v205 coexistence report path added in the preceding commit.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-4-pkshih@realtek.com
|
|
Define struct rtw89_btc_fbtc_rpt_ctrl_v205 and add it to the
rtw89_btc_fbtc_rpt_ctrl_ver_info union. Wire up the v205 dispatch
path in _chk_btc_report() including req_len, fver extraction, and
rsp_fver assignment (H2C fver=5). Decode the v205 report block for
rpt_en_map, fw_coex/fw version, cx_offload, build timestamps, gnt_val,
and BT counters. Add fw_ver_match checking for fcxbtcrpt=205, and add
BTTX_HANG detection in the v205 error-check block.
Also add _show_summary_v205() and wire it into the coex info dump so
the fcxbtcrpt=205 statistics block is printed instead of skipped.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-3-pkshih@realtek.com
|
|
_chk_btc_report() validated the reported firmware struct version only
for the control report, so a version mismatch on any other report type
was copied in silently and left no trace, making a ver_defs or firmware
version error hard to diagnose.
Read the reported fver, which is the leading field of every report
struct, and when it differs from the driver-selected version set the
per-type bit in fver_mismch and emit a debug line. The length-valid
report is still processed, because the driver must stay compatible with
every released firmware and a mismatch usually points at a ver_defs
entry that needs fixing rather than a report that should be discarded.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260923071354.50864-2-pkshih@realtek.com
|
