net: macb: v2 follow-ups to silent TX stall fix series (PR #7340)

[lukaszraczylo]

Three follow-up commits to PR #7340 (merged 2026-05-08) addressing one regression and two operational polish items I found while preparing the netdev v2 submission.

Background

Mainline RFC: https://lore.kernel.org/netdev/cover.1777064117.git.lukasz@raczylo.com/T/
Mainline v2 sent today (2026-05-14): https://lore.kernel.org/netdev/ (cover Message-ID <20260514215459.36109-1-lukasz@raczylo.com>)

These rpi-6.18.y-anchored commits track the mainline v2 changes one-for-one but apply on top of the already-merged form in this tree.

Commits

1. net: macb: gate PCIe posted-write flush behind MACB_CAPS_PCIE_POSTED_WRITES

@a9e13da2dc4c added the NCR readback unconditionally to every macb variant. SoC-integrated parts (Atmel, Microchip, SiFive, Xilinx, etc.) write NCR over on-chip MMIO with no fabric posted-write concern, so they pay the non-posted-read latency for nothing.

Introduce MACB_CAPS_PCIE_POSTED_WRITES (BIT(14) — first unused) and gate both readbacks behind it. Set on raspberrypi_rp1_config only.

2. net: macb: drop destructive ISR read, use IMR barrier in macb_tx_poll ← the real regression fix

@ff6914e97386 added if ((queue_readl(queue, ISR) & MACB_BIT(TCOMP)) || macb_tx_complete_pending(queue)). On read-clear ISR silicon — which is what raspberrypi_rp1_config defaults to (MACB_CAPS_ISR_CLEAR_ON_WRITE not set) — the queue_readl(queue, ISR) consumes every bit set in the register, but the use-site masks down to TCOMP and discards the rest. Any RCOMP / ROVR / TXUBR bit set at the moment of the read is silently consumed; the IRQ handler that would have processed it sees ISR == 0 and returns IRQ_NONE. On a level-triggered IRQ the consumed bit drops the line before GIC delivery, so the IRQ vanishes entirely.

Race window is ~200-500 ns per macb_tx_poll completion; small but non-zero, and at moderate-to-heavy RX load the math works out to non-negligible RX-completion loss.

Replace with (void)queue_readl(queue, IMR). IMR is the read-only mask mirror, no side effects on either read-clear or W1C ISR silicon. Same PCIe-barrier effect, so the subsequent macb_tx_complete_pending() still sees flushed peripheral DMA writes. Loses the "directly sample latched TCOMP" half of the original change; keeps the half that addresses the documented rmb() race.

3. net: macb: gate TX stall watchdog on netif_carrier_ok, use warn_ratelimited

@79dc190b12f9 's watchdog fires a false positive at boot when tx_head advances from kernel-queued packets between macb_open() and link autoneg completion while tx_tail stays at 0 (no TCOMPs yet). Observed at ~25% rate during a 24-node fleet rolling reboot (6 of 24 nodes fired with the canonical tail=0 head=5-7 signature).

The re-kick itself is harmless (macb_tx_restart() checks TBQP vs head before re-asserting TSTART) but the warning is misleading.

Two changes:

• Add a netif_carrier_ok() gate at the top of the watchdog tick. No carrier means no completion possible; skip the check but keep ticking.
• Swap netdev_warn_once → netdev_warn_ratelimited so operators can count real events over time without floods.

Testing

• All three commits running in production on a 24-node Raspberry Pi 5 fleet on rpi-6.18.y + macb-v2 since 2026-05-14 ~14:00 UTC. ~120 cumulative node-hours so far. Zero mid-runtime TX stalls; zero user-space-watchdog RECOVER events; the five TX stall detected lines in dmesg are all the boot-time false positive the carrier-gate commit eliminates.

• Pre-patch fleet rate was multiple stalls per hour at fleet level ([JFYI] Raspberry Pi 5 + kernel 6.17: Silent network death cilium/cilium#43198, Ubuntu launchpad #2133877). Pre-patch baseline over the same 120 node-hours would have predicted ~60 stalls; observed: 0.

• checkpatch clean on all three commits.

Happy to split / squash / rebase on feedback. CC @pelwell who reviewed the original series.