[JuliusBairaktaris]

Hi @Ansuel — thanks again for the qca-edma rework. Along the way I hit a silent per-port egress wedge that traces back to qca_ppe link handling; this PR fixes it.

The fix (one commit, qca_ppe_main.c only)

On a carrier flap, qca_ppe_mac_link_down() disables only the port MAC (ppe_port_gmac_set(..., false, false)) and leaves the PPE switch-fabric TX-MAC (PPE_PORT_BRIDGE_CTRL_TXMAC_EN) forwarding into the port. At the down→up edge the fabric can then dequeue into a MAC that is still being re-clocked, which latches the port's Queue-Manager egress scheduler into a state that no longer drains: the link comes back at full speed and the host still hands frames to the port, but nothing egresses the wire — a silent, per-port egress black-hole that clears only on reboot.

The reference ssdk switch driver gates the bridge TX-MAC across every link change — disabling it first on link-down (its own comment: "release ppe port egress packets when link down") and re-enabling it last on link-up, after the MAC is back up (qca_hppe_mac_sw_sync_task, src/adpt/hppe/adpt_hppe_portctrl.c, tag NHSS.QSDK.14.0.r8-00026-O). The qca_ppe rewrite dropped that gating. This PR restores it, reusing the existing ppe_port_bridge_txmac_set() helper: disable it before the MAC teardown in mac_link_down, and re-enable it as the final step of mac_link_up. No new API; device-agnostic (flat per-port PPE_PORT_BRIDGE_CTRL register, no port mask); covers both the GMAC and XGMAC cases.

Scope — where it actually bites

I hit this on the NSS offload path, where the firmware injects into a port's egress queue decoupled from the host's MAC-ready state, so it bursts into the cold-MAC window right at link-up. On the plain EDMA datapath (no NSS) I could not reproduce it across many flaps at up to ~420 Mbit host-forwarded load — there the host TX is gated by netif_carrier_on, which follows mac_link_up, so it never bursts into a re-clocking MAC. So for a pure-EDMA user this is mostly defensive / ssdk-parity; it's load-bearing for NSS offload. Either way qca_ppe's link path is objectively missing the fabric gating ssdk does, and the change is harmless on plain EDMA too (I confirmed the bit gates host egress cleanly and is re-enabled last).

How to reproduce (NSS offload build)

1. Drive a sustained high-rate download to a wired client on an offloaded LAN port (~40+ accelerated flows, ~350 Mbit; e.g. iperf3 -u -R -P 8 from a few servers).
2. Force a long carrier-down on that port for ≥40–60 s while the load runs — a real cable pull works, or an MDIO PHY power-down (write BMCR 0x1800 to the port PHY, then 0x1200 to bring it back).
3. On link-up, watch the port's QM per-queue occupancy (AC_UNI_QUEUE_CNT_TBL, 0x3a84e000 + qid*0x10, low 12 bits) for the port's base queue: without the fix it pins at its ceiling and the client's egress is dead (0 bytes) until reboot; with the fix it stays ~0 and egress survives. PPE_PORT_BRIDGE_CTRL(port) (0x3a060300 + port*4, bit 16) reads 0 during the down and 1 again after up, confirming the gating fires.

Validated on a Xiaomi AX3600 (IPQ8074): the unpatched driver wedges on the first flap; the patched driver survives 8/8 flaps at 68 accelerated flows.

Thanks!

[Copilot]

Pull request overview

This PR addresses a Qualcomm PPE (qca_ppe) link-handling corner case where, on carrier flaps, the PPE switch-fabric can continue dequeuing into a port MAC while it is being torn down / re-clocked. The change restores the “bridge TX-MAC” gating behavior used by the reference SSDK driver to prevent silent per-port egress wedges (notably observed on NSS offload).

Changes:

• Disable PPE_PORT_BRIDGE_CTRL_TXMAC_EN on mac_link_down() before MAC teardown.
• Re-enable PPE_PORT_BRIDGE_CTRL_TXMAC_EN on mac_link_up() as the final step after MAC bring-up.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JuliusBairaktaris]

The qca-edma rework is merged into openwrt/main now, so this moves upstream to openwrt#24188. Closing here — thanks @Ansuel.