Firmware may return wlan_failure when deactivating a BSS that is already
inactive. This is a valid teardown case and should not fail the remove
path.
Keep activation failures unchanged since they still indicate that firmware
failed to create or activate the BSS state.
Signed-off-by: Sean Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
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]>
When MT76_NPU and CONFIG_NET_MEDIATEK_SOC_WED are enabled and
mt76 detects properly the Airoha NPU SoC, mt7996_init_tx_queues() will
dereference a NULL WED pointer.
Fix the issue by always passing the WED pointer from mt7996_dma_init().
Fixes: cd7951f242a7 ("wifi: mt76: mt7996: Integrate MT7990 dma configuration for NPU")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree()
after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents
future RCU readers from obtaining the pointer -- it does not wait for
existing readers that already hold it via rcu_dereference.
The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid
and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer
via rcu_dereference just before the NULL assignment, it will dereference
freed memory after the kfree.
struct mt76_vif_link already contains an rcu_head field that is unused at
this free site -- a developer oversight, since the adjacent
kfree_rcu_mightsleep call for rx_sc in the same function shows the
pattern was understood.
Replace kfree(mlink) with kfree_rcu(mlink, rcu_head).
Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions")
Signed-off-by: Rajat Gupta <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
On a STATION vif, removing a TDLS peer takes the mt7925_mac_sta_remove
-> mt7925_mac_sta_remove_links path. The first loop in that function
calls mt7925_mcu_add_bss_info(..., enable=false) for every link of the
station being removed. For a non-MLO STATION vif there is exactly one
link, link 0, whose bss_conf is the AP's. TDLS peers do not have their
own bss_conf - they share the AP's BSS.
The result is that every TDLS peer teardown sends a BSS_INFO_UPDATE
with enable=0 for the AP's BSS to the firmware, which wipes the AP-side
rate-control context. The connection stays associated and TX from the
host still works at the negotiated rate, but the AP's downlink to us
collapses to the lowest mandatory OFDM rate (HE-MCS 0 / 6 Mbit/s OFDM)
and only slowly recovers as rate adaptation re-learns under sustained
traffic. With brief or bursty traffic the link can stay at 6-72 Mbit/s
indefinitely, requiring a manual reconnect.
mt7925_mac_link_sta_remove() already guards its own
mt7925_mcu_add_bss_info(..., false) call with
"vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls".
Add the equivalent guard at the top of the cleanup loop in
mt7925_mac_sta_remove_links(), above the link_sta / link_conf /
mlink / mconf lookups, so TDLS peer teardown skips the loop body
entirely without doing the per-link work that would just be thrown
away.
Verified on mt7925e by triggering Samsung-S938B auto-TDLS via iperf3
and watching iw rx bitrate after teardown:
Before: rx bitrate collapses to 6.0-72.0 Mbit/s, oscillates 17/72/
137/288/432 Mbit/s for 30+ seconds, no full recovery without
a manual reassoc.
After: rx bitrate stays at 1200.9 Mbit/s HE-MCS 11 NSS 2 80 MHz
across the entire TDLS lifecycle.
bpftrace confirms a single mt7925_mcu_add_bss_info(enable=0) call per
teardown before the fix; zero such calls after.
Fixes: 3878b4333602 ("wifi: mt76: mt7925: update mt7925_mac_link_sta_[add, assoc, remove] for MLO")
Cc: [email protected]
Signed-off-by: ElXreno <[email protected]>
Assisted-by: Claude:claude-opus-4-7 bpftrace
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
With HW TX encap offload enabled, the mt76 firmware builds the 802.11
header for the 802.3 frame using the per-WCID context. For a STATION
vif the HDR_TRANS TLV currently sets ToDS=1, which makes the firmware
default to the BSSID as A1 and emit STA->AP-formatted frames
regardless of which peer the WCID points to.
For TDLS-paired peers this is wrong. Data frames go on air addressed
to the AP, the AP MAC-ACKs and silently drops them per IEEE 802.11z
(an AP must not forward to a TDLS-paired peer). Management and
control frames bypass the HW encap path and still reach the peer;
only user data fails.
Add MT_WCID_FLAG_TDLS_PEER, set it in mt7915, mt7921, mt7925 and
mt7996 sta-add paths when sta->tdls is true, and override the
HDR_TRANS TLV in mt76_connac_mcu_wtbl_hdr_trans_tlv() (Connac2 -
mt7915 / mt7921 / mt7922), mt7925_mcu_sta_hdr_trans_tlv() (mt7925)
and mt7996_mcu_sta_hdr_trans_tlv() (mt7996) to set ToDS=0, FromDS=0
when the flag is set. The 3-addr non-DS form matches what 802.11z
uses for direct links; the firmware then constructs the frame with
A1=peer rather than A1=BSSID. HW encap offload remains enabled for
AP and any non-TDLS traffic.
Verified on mt7925e + Samsung S938B over a 5 GHz HE 80 MHz channel
with iperf3 -t 30 to the TDLS peer:
before fix: over the TDLS direct link, 7 TDLS Setup action
frames and 3 RTS frames reach the peer; 0 QoS
Data frames make it through (mgmt/control paths
bypass HW encap, the data path does not). iperf3
stalls.
after fix: 2.90 GBytes transferred at 830 Mbit/s sustained,
0 TCP retransmits.
mt7915, mt7921, mt7922 and mt7996 are not regression-tested in this
change for lack of hardware. Their HDR_TRANS handling mirrors the
verified mt7925 change; the firmware behavior is shared across these
chips.
Signed-off-by: ElXreno <[email protected]>
Assisted-by: Claude:claude-opus-4-7 bpftrace tcpdump
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
This patch is based on a BUG as reported by Bongani Hlope at
https://lore.kernel.org/all/[email protected]/
When a channel-switch announcement (CSA) beacon is received,
cfg80211 queues a wiphy work item that eventually calls
mt7921_channel_switch_rx_beacon(). If the station disconnects
(or the channel context is otherwise torn down) between the
time the work is queued and the time it runs, the driver's
dev->new_ctx pointer can already have been cleared to NULL.
mt7921_channel_switch_rx_beacon() then dereferences new_ctx
unconditionally, triggering a NULL pointer dereference at
address 0x0:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:mt7921_channel_switch_rx_beacon+0x1f/0x100 [mt7921_common]
The same missing guard exists in mt7925_channel_switch_rx_beacon(),
which shares the same code pattern introduced by the same commit.
Add an early-return NULL check for dev->new_ctx in both
mt7921_channel_switch_rx_beacon() and
mt7925_channel_switch_rx_beacon(). When new_ctx is NULL there is
no pending channel switch to process, so returning immediately is
the correct and safe action.
Fixes: 8aa2f59260eb ("wifi: mt76: mt7921: introduce CSA support")
Reported-by: Bongani Hlope <[email protected]>
Oops-Analysis: http://oops.fenrus.org/reports/lkml/[email protected]/report.html
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Arjan van de Ven <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Felix Fietkau <[email protected]>
Cc: Lorenzo Bianconi <[email protected]>
Cc: Ryder Lee <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
When pcim_iomap_region() or devm_kmemdup() fail, the code returns
directly without cleaning up previously allocated resources:
- mt76_device allocated by mt76_alloc_device()
- pci irq vectors allocated by pci_alloc_irq_vectors()
Fix this by jumping to the existing error cleanup path instead of
returning directly.
Fixes: ee5bb35d2b83 ("wifi: mt76: mt7921: switch to pcim_iomap_region")
Signed-off-by: Hongling Zeng <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
mt76_dma_cleanup() already disables tx napi before deleting it, but
it still removes rx napi instances while they can remain enabled on the
normal device remove path. On mt7915 this triggers a warning.
Disable each rx napi instance before netif_napi_del() and page pool
destruction. This fixes repeated warnings on rmmod mt7915e on
mt7915e/mt7981b.
Signed-off-by: Ruslan Isaev <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
mt7925_pci_probe() initializes DMA before registering the device. If
mt7925_register_device() fails, probe returns through err_free_irq without
tearing down DMA state.
That leaves the TX NAPI instance enabled and skips the DMA queue cleanup
that the normal remove path performs through mt7925e_unregister_device().
Add a dedicated unwind label for failures after mt7925_dma_init() succeeds.
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Co-developed-by: Ijae Kim <[email protected]>
Signed-off-by: Ijae Kim <[email protected]>
Signed-off-by: Myeonghun Pak <[email protected]>
Link: https://patch.msgid.link/20260426143728.41534-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local
Signed-off-by: Felix Fietkau <[email protected]>
Enable MT_DRV_HW_PS_BUFFERING and handle MCU_UNI_EVENT_PS_SYNC with
all three TLV formats (single client, multi-client packed entries,
and bitmap).
Signed-off-by: Felix Fietkau <[email protected]>
Enable MT_DRV_HW_PS_BUFFERING and handle MCU_EXT_EVENT_PS_SYNC to
track station power-save state via firmware notifications.
Signed-off-by: Felix Fietkau <[email protected]>
Add MT_DRV_HW_PS_BUFFERING flag for drivers where firmware controls
the TIM bit based on buffered frames. Instead of blocking all TX to
PS stations (which starves firmware and prevents TIM from being set),
allow limited frame delivery using AQL pending airtime as the
throttle. Replenish the firmware buffer on TX completion.
Add mt76_sta_ps_transition() helper for drivers to call from MCU
PS sync events.
Signed-off-by: Felix Fietkau <[email protected]>
Replace the two-step hrtimer initialization pattern with a single
consolidated call to hrtimer_setup().
The legacy approach of calling hrtimer_init() followed by manual
assignment to timer.function is deprecated. The new hrtimer_setup()
helper atomically initializes the timer and assigns the callback
function in one operation, eliminating the race-prone intermediate
state where the timer is initialized but lacks a handler.
Signed-off-by: Mieczyslaw Nalewaj <[email protected]>
Similar to vif link management, postpone sta link destuction in
mt7996_mac_sta_remove() introducing mt7996_mac_sta_remove_link utility
routine and just disable sta link running mt7996_mac_sta_remove_links
routine.
This is a preliminary patch in order to support MLO link reconfiguration
in MT7996 driver.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Introduce mt7996_mcu_mld_reconf_stop_link and mt7996_mcu_mld_link_oper
utility routines in order to communicate to the mcu fw to disable/enable
a specific vif link. Please note these APIs are currently supported by
the MT7996 firmware only in AP mode.
Signed-off-by: Shayne Chen <[email protected]>
Co-developed-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
MT7996 hw requires to remove active links from the mcu BSSINFO table
destroying the interface. For this reason introduce mt7996_vif_link_destroy
routine and remove active (non-offchannel) vif links running
mt7996_remove_interface routine.
This is a preliminary patch in order to support MLO link reconfiguration
in MT7996 driver.
Co-developed-by: Shayne Chen <[email protected]>
Signed-off-by: Shayne Chen <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Destroy mt76_vif_link struct in mt7996_vif_link_remove routine and not
in mt76_unassign_vif_chanctx(). This is necessary since, in order to
properly support MLO link reconfiguration, we will destroy mt76_vif_link
struct during AP tear-down process and not running unassign_vif_chanctx
mac80211 callback.
This patch does not introduce any regression since
mt76_assign_vif_chanctx/mt76_unassign_vif_chanctx APIs are currently
used just by MT7996 driver.
Signed-off-by: Shayne Chen <[email protected]>
Co-developed-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Track active vif links in mt7996_vif_link_add and mt7996_vif_link_remove
routines.
This is a preliminary patch in order to remove AP MLD links from MCU
configuration during AP tear-down process and to support MLO link
reconfiguration in MT7996 driver.
Signed-off-by: Shayne Chen <[email protected]>
Co-developed-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Rely on msta_link link_id value in mt7996_vif_link_remove routine
instead of using link_conf pointer. This assumption is correct since
msta_link link_id is set to link_conf link_id value in mt7996_vif_link_add
routine.
Moreover, fallback to default ieee80211_bss_conf struct if the link_conf
pointer in mt7996_vif_link_remove() is NULL.
MT7996 hw requires to remove AP MLD links from MCU configuration during
AP tear-down process (e.g. running mt7996_remove_interface()). Doing so,
we can't assume link_conf pointer is always non-NULL running
mt7996_vif_link_remove routine.
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Do not switch default link to the secondary link in
mt7996_mac_sta_remove_links routine if the lookup for the secondary
msta_link fails.
Fixes: d7e5444f9eb02 ("wifi: mt76: mt7996: Switch to the secondary link if the default one is removed")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
When associated with a nontransmitted BSS in an MBSSID set, the beacon
frame's BSSID (addr3) contains the transmitting AP's BSSID, not the
station's associated BSSID. The beacon matching in mt76_rx_beacon_iter()
only compared against link_conf->bssid, so beacons were never matched,
causing false beacon loss reports.
Add a fallback check against link_conf->transmitter_bssid when
link_conf->nontransmitted is set, mirroring mac80211's
ieee80211_rx_our_beacon() logic.
Signed-off-by: Felix Fietkau <[email protected]>
Release host link resources when mt7925_mac_sta_add_links() fails after
partial success.
msta->link[] and dev->mt76.wcid[] may already be published, so unwind
the host state to avoid leaving stale links behind.
Signed-off-by: Sean Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Move the msta->link[link_id] publication until after
mt7925_mac_link_sta_add() succeeds.
msta->link[] is RCU-visible, so publishing it before setup completes can
expose a link whose add path later fails. Publish it only after success
to avoid partially initialized link state becoming visible.
Signed-off-by: Sean Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Allocate mt792x_link_sta with kzalloc() and free it with kfree_rcu()
instead of devm-managed memory.
msta->link[] is published via RCU, so the link STA must remain valid
until readers have quiesced after teardown. Manage the object lifetime
with kfree_rcu() to match its RCU-visible publication.
Signed-off-by: Sean Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Move WCID teardown into mt7925_mac_link_sta_remove() to mirror the
dev->mt76.wcid[] publish done during link add.
This clears the published WCID before the rest of teardown, so WCID
lookups no longer expose a link that is being removed.
No functional change intended.
Signed-off-by: Sean Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Remove the redundant mt76_wcid_init() call after publishing the WCID in
mt7925_mac_link_sta_add().
WCID is already initialized before publication, so reinitializing it
afterward is unnecessary and makes the setup ordering less clear.
No functional change intended.
Signed-off-by: Sean Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
