Tags: rmandrad/BPI-Router-Linux
Tags
kernel: bump to 7.1.5 Apply the 7.1.4 -> 7.1.5 stable update (patch-7.1.4-5.xz) and reconcile the two downstream MediaTek drivers whose consumers the stable rework did not update: - net: mediatek: mtk_ppe_offload: drop the ext->gen_id check in mtk_nf_conn_acct_find(). 7.1.5 removes the conntrack extension genid mechanism (struct nf_ct_ext.gen_id, __nf_ct_ext_find()), so the field no longer exists. This matches the in-tree nf_conn_acct_find() helper. - wifi: mt76: mt7996: revert the two mt7996_mac_write_txwi() beacon / inband-discovery call sites to the 8-arg form. The stable patch added a trailing link_id argument to these callers but its matching signature rework (key instead of tx_info, drop internal link_id derivation) did not apply on this divergent tree, and porting it would revert the local EAPOL-source-BSS fix. The callers hit the wcid == global_wcid path where link_id is already resolved from info->control.flags. - mt7988a-bananapi-bpi-r4-pro.dtsi: Not implemented as it removes output-high from two PCIe gpio-hogs (pcie-2-hog gpio 79, pcie-3-hog gpio 63 — the CN14/CN18 lane-mux/power pins) This change caused the board to hang at boot hence the revert. Signed-off-by: Rudy Andram <rmandrad@gmail.com>
wifi: mt76: mt7996: fix non-MLD station num_sta leak
The MLO link-reconfiguration rework moved the per-phy num_sta
decrement inside a link_valid guard. link_valid is only set for
MLO links, but num_sta is incremented for every station link,
including the non-MLO deflink. Non-MLO stations bump num_sta
on association and never drop it on removal.
A non-zero num_sta forces connected-mode off-channel scanning which
prevents the directed probe exchange needed to find hidden APs.
Decrement phy->num_sta on the actual link teardown, pairing it with
the unconditional increment on link creation.
Fixes: 018f603 ("wifi: mt76: mt7996: Destroy active sta links in mt7996_mac_sta_remove()")
Signed-off-by: Chad Monroe <chad@monroe.io>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rudy Andram <rmandrad@gmail.com>
wifi: mt76: mt7996: fix non-MLD station num_sta leak
The MLO link-reconfiguration rework moved the per-phy num_sta
decrement inside a link_valid guard. link_valid is only set for
MLO links, but num_sta is incremented for every station link,
including the non-MLO deflink. Non-MLO stations bump num_sta
on association and never drop it on removal.
A non-zero num_sta forces connected-mode off-channel scanning which
prevents the directed probe exchange needed to find hidden APs.
Decrement phy->num_sta on the actual link teardown, pairing it with
the unconditional increment on link creation.
Fixes: 018f603 ("wifi: mt76: mt7996: Destroy active sta links in mt7996_mac_sta_remove()")
Signed-off-by: Chad Monroe <chad@monroe.io>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rudy Andram <rmandrad@gmail.com>
wifi: mt76: mt7996: fix non-MLD station num_sta leak
The MLO link-reconfiguration rework moved the per-phy num_sta
decrement inside a link_valid guard. link_valid is only set for
MLO links, but num_sta is incremented for every station link,
including the non-MLO deflink. Non-MLO stations bump num_sta
on association and never drop it on removal.
A non-zero num_sta forces connected-mode off-channel scanning which
prevents the directed probe exchange needed to find hidden APs.
Decrement phy->num_sta on the actual link teardown, pairing it with
the unconditional increment on link creation.
Fixes: 018f603 ("wifi: mt76: mt7996: Destroy active sta links in mt7996_mac_sta_remove()")
Signed-off-by: Chad Monroe <chad@monroe.io>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rudy Andram <rmandrad@gmail.com>
wifi: mt76: mt7996: restore blink mode in mt7996_led_set_config() Commit 0fdedf9 ("mt76: mt7996 - implement a true steady-on LED state for mt7996") added a dedicated steady-on branch and moved the TCR0 TX_BLINK write down into the blink branch, but in doing so dropped the val = MT_LED_CTRL_BLINK_MODE | MT_LED_CTRL_KICK; if (mphy->band_idx == MT_BAND1) val |= MT_LED_CTRL_BLINK_BAND_SEL; assignment that used to terminate that branch. Three problems follow. 'val' is left uninitialised on the blink path. It is subsequently read ("val |= MT_LED_CTRL_POLARITY") and written to MT_LED_CTRL, so stack garbage reaches a hardware register. MT_LED_CTRL_BLINK_MODE is now never set on any path, so the MAC blink engine is never selected and the LED does not blink at all. This is the inverse of the original intent, which was to stop every brightness write collapsing into blink. MT_LED_CTRL_BLINK_BAND_SEL is no longer set for MT_BAND1, so that band's LED would source its blink from the wrong band. The blink path is reachable in normal operation via blink_set() from the throughput LED trigger, which commit 4d8c873 ("wifi: mt76: share throughput LED trigger and expose per-band LEDs") wires up on every band rather than only the primary phy. Restore the assignment, keeping both intentional changes from the original commit: the TCR0 write stays scoped to the blink branch and the steady-on branch is untouched. The effect is confined to the LED register block (MT_LED_CTRL is MT_LED_PHYS(0x00 + _n * 4)); no RF or TX behaviour is involved. Fixes: 0fdedf9 ("mt76: mt7996 - implement a true steady-on LED state for mt7996") Signed-off-by: Rudy Andram <rmandrad@gmail.com>
mt76: mt7996 - implement a true steady-on LED state for mt7996 mt7996_led_set_brightness() maps any non-zero brightness to mt7996_led_set_config(0xff, 0), but set_config() only has a static output path for the OFF tuple (0, 0xff). Every other combination - including the "on" tuple - programs MT_LED_CTRL_BLINK_MODE, handing the LED to the MAC TX-blink engine (TCR0 TX_BLINK=2, data frames only). As a result "echo default-on > trigger" (and any userspace brightness write) produces traffic-driven blinking instead of a solid LED. There is currently no way to get a steady-on LED at all. taken from frank-w@6dc86df Signed-off-by: Rudy Andram <rmandrad@gmail.com>
netfilter: nf_flow_table: add DEV_PATH_MTK_WDMA to path resolution nft_dev_path_info() has no case for DEV_PATH_MTK_WDMA, the path element mt7996's net_fill_forward_path() returns for wifi egress via WED. For a bridged wifi client this produces a path stack of [DEV_PATH_BRIDGE, DEV_PATH_MTK_WDMA], and the WDMA element falls through to default, which clears info->indev and aborts hardware flow-offload resolution entirely. The effect: download-direction flows (egress via the wifi netdev) could never be hardware-offloaded, forcing all such traffic through software routing, while upload-direction flows (egress via a plain ethernet WAN port) offloaded normally -- confirmed via the PPE flow table showing this exact directional split, with zero download flows ever reaching BND state. Fixing this took a WAN throughput test from ~100Mbps to 1.3Gbps. Set info->indev to the WDMA path's device so the existing bridge/ flowtable-membership and redirect-device logic downstream resolves normally, letting mtk_flow_get_wdma_info() succeed. Signed-off-by: Rudy Andram <rmandrad@gmail.com>
wifi: mt76: mt7996: reassemble multi-buffer WED-RRO MSDUs mt7996_rro_rx_process() silently dropped any MSDU that spanned more than one hardware RX buffer (over MT_RX_BUF_SIZE, e.g. jumbo frames or large 802.11be A-MSDU aggregation): continuation segments were freed instead of appended, and the accumulated skb was discarded once the last segment arrived. Use mt76_add_rx_frag() to append continuation segments as skb frags, mirroring the existing mt76_dma_rx_process()/mt76_add_fragment() pattern. Consolidate the first-segment and final-segment paths into one finalization block so ind_reason/rx_check/status->aggr handling runs exactly once per reassembled MSDU, which also fixes a related bug where an ind_reason-dropped first segment left rx_head NULL and caused its continuation segments to be misread as a new MSDU. Signed-off-by: Rudy Andram <rmandrad@gmail.com>
PreviousNext