Disable PCIe ASPM unconditionally for MT7927. The CONNINFRA power
domain and WFDMA register access are unreliable with PCIe L1 active,
causing throughput to drop from 1+ Gbps to ~200 Mbps.
Disable runtime PM and deep sleep for MT7927. The combo chip shares
a CONNINFRA power domain between WiFi (PCIe) and BT (USB).
SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
firmware, requiring a full power cycle to recover. PM enablement will
be addressed in a follow-up once safe power state transitions are
determined.
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
The mac_reset and resume paths use the hardcoded MT_INT_RX_DONE_ALL
constant (bits 0-2) to re-enable RX interrupts. This is correct for
MT7925 (RX rings 0, 1, 2) but wrong for chips using different ring
indices.
Define a per-chip irq_map with the correct RX interrupt enable bits and
replace hardcoded MT_INT_RX_DONE_ALL with irq_map field reads in the
resume and mac_reset paths. Add the MT7927 irq_map with interrupt bits
matching its RX ring layout (rings 4, 6, 7), selected at probe time
based on PCI device ID.
This ensures the correct interrupt bits are enabled regardless of the
chip variant.
Tested-by: Marcin FM <[email protected]>
Tested-by: Cristian-Florin Radoi <[email protected]>
Tested-by: George Salukvadze <[email protected]>
Tested-by: Evgeny Kapusta <[email protected]>
Tested-by: Samu Toljamo <[email protected]>
Tested-by: Ariel Rosenfeld <[email protected]>
Tested-by: Chapuis Dario <[email protected]>
Tested-by: Thibaut François <[email protected]>
Tested-by: 张旭涵 <[email protected]>
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80
and BW = 160, but never sets BW = 320. This means iw phy shows no
320MHz MCS map entries even though the hardware supports 320MHz
operation in the 6GHz band.
Add the missing 320MHz capability bits for 6GHz:
- PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ
- PHY_CAP1: beamformee SS for 320MHz
- PHY_CAP2: sounding dimensions for 320MHz
- PHY_CAP6: MCS15 support for 320MHz width
- MCS/NSS: populate bw._320 maps for 6GHz band
Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since
MT7925 does not support 320MHz operation.
Tested-by: Marcin FM <[email protected]>
Tested-by: Cristian-Florin Radoi <[email protected]>
Tested-by: George Salukvadze <[email protected]>
Tested-by: Evgeny Kapusta <[email protected]>
Tested-by: Samu Toljamo <[email protected]>
Tested-by: Ariel Rosenfeld <[email protected]>
Tested-by: Chapuis Dario <[email protected]>
Tested-by: Thibaut François <[email protected]>
Tested-by: 张旭涵 <[email protected]>
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
The sta_rec_eht structure has a mcs_map_bw320 field, and the channel
width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS
map was never copied from the station's EHT capabilities to the MCU TLV.
This prevents negotiation of 320MHz channel width even when both the
hardware and firmware advertise support for it.
Add the missing memcpy for the 320MHz MCS map, matching the existing
pattern for BW20, BW80, and BW160.
Tested-by: Marcin FM <[email protected]>
Tested-by: Cristian-Florin Radoi <[email protected]>
Tested-by: George Salukvadze <[email protected]>
Tested-by: Evgeny Kapusta <[email protected]>
Tested-by: Samu Toljamo <[email protected]>
Tested-by: Ariel Rosenfeld <[email protected]>
Tested-by: Chapuis Dario <[email protected]>
Tested-by: Thibaut François <[email protected]>
Tested-by: 张旭涵 <[email protected]>
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
The RX vector (RXV) and TX status (TXS) parsing in mac.c lack handling
for 320MHz channel width. When the hardware reports 320MHz in the
bandwidth field, mt7925_mac_fill_rx_rate() returns -EINVAL and
mt7925_mac_add_txs_skb() records no bandwidth stats.
Add IEEE80211_STA_RX_BW_320 cases to both functions. The RXV parser
also handles BW_320+1 since the hardware can report 320MHz in two
adjacent encoding positions.
Tested-by: Marcin FM <[email protected]>
Tested-by: Cristian-Florin Radoi <[email protected]>
Tested-by: George Salukvadze <[email protected]>
Tested-by: Evgeny Kapusta <[email protected]>
Tested-by: Samu Toljamo <[email protected]>
Tested-by: Ariel Rosenfeld <[email protected]>
Tested-by: Chapuis Dario <[email protected]>
Tested-by: Thibaut François <[email protected]>
Tested-by: 张旭涵 <[email protected]>
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for
NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch
falls through to default and sends bw=0 (CMD_CBW_20MHZ) to firmware
via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz
and cannot decode the AP's 320MHz frames, resulting in complete data
path failure at 320MHz.
Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and
center_chan2.
Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to
841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11.
Reported-by: 张旭涵 <[email protected]>
Closes: https://github.com/openwrt/mt76/issues/927
Tested-by: 张旭涵 <[email protected]>
Tested-by: Marcin FM <[email protected]>
Tested-by: Cristian-Florin Radoi <[email protected]>
Tested-by: George Salukvadze <[email protected]>
Tested-by: Evgeny Kapusta <[email protected]>
Tested-by: Samu Toljamo <[email protected]>
Tested-by: Ariel Rosenfeld <[email protected]>
Tested-by: Chapuis Dario <[email protected]>
Tested-by: Thibaut François <[email protected]>
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
In the error path of mt7925_change_vif_links(), the free: label iterates
over link_ids to clean up, but compares against `mconf` and `mlink`
which hold stale values from the last loop iteration rather than the
current link_id being freed.
Use array-indexed access (mconfs[link_id] / mlinks[link_id]) to compare
against the correct per-link pointers.
Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links")
Tested-by: Marcin FM <[email protected]>
Tested-by: Cristian-Florin Radoi <[email protected]>
Tested-by: George Salukvadze <[email protected]>
Tested-by: Evgeny Kapusta <[email protected]>
Tested-by: Samu Toljamo <[email protected]>
Tested-by: Ariel Rosenfeld <[email protected]>
Tested-by: Chapuis Dario <[email protected]>
Tested-by: Thibaut François <[email protected]>
Tested-by: 张旭涵 <[email protected]>
Reviewed-by: Sean Wang <[email protected]>
Signed-off-by: Javier Tia <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
