kernel: macb silent TX stall — v2 patch series

Update the three net-macb silent-TX-stall patches from RFC v1 to
PATCH net-next v2.  The v2 series is on lore at:

  https://lore.kernel.org/netdev/20260514215459.36109-1-lukasz@raczylo.com/T/

v2 changes from v1 (already merged in #1526):

  * 0001 (PCIe posted-write flush after TSTART doorbell) — now gated
    behind a new MACB_CAPS_PCIE_POSTED_WRITES capability, set only on
    raspberrypi_rp1_config.  v1 applied the readback to every macb
    variant; SoC-integrated parts (Atmel, Microchip, SiFive, Xilinx)
    have no fabric posted-write concern and were paying the
    non-posted-read latency for nothing.

  * 0002 (PCIe read barrier before TX completion descriptor check) —
    replaces the v1 form, which was a regression on read-clear ISR
    silicon.  v1 read ISR with a TCOMP mask in macb_tx_poll(); on
    raspberrypi_rp1_config (where MACB_CAPS_ISR_CLEAR_ON_WRITE is
    not set) that read consumes every bit set in ISR, but the
    use-site masks down to TCOMP and discards the rest -- any
    RCOMP / ROVR / TXUBR bit at that instant is silently consumed
    and the IRQ handler that would have processed it sees ISR=0.
    On level-triggered IRQ the consumed bit drops the line before
    GIC delivery, vanishing the IRQ entirely.  Caught by self-audit
    while preparing v2; disclosed to netdev in the reply thread.
    v2 replaces the destructive ISR read with (void)queue_readl(
    queue, IMR), the read-only mask mirror -- non-destructive, same
    PCIe-barrier effect on prior peripheral DMA writes.

  * 0003 (TX stall watchdog) — tracks tail movement via a bool flag
    set by macb_tx_complete() instead of a tx_tail snapshot
    (form suggested by Phil Elwell on raspberrypi/linux#7340).
    Adds a netif_carrier_ok() gate at the top of the watchdog tick
    so the boot-time false positive seen on autoneg-still-pending
    boots no longer fires (observed at ~25% rate on a 24-node fleet
    rolling reboot under v1).  Swaps netdev_warn_once to
    netdev_warn_ratelimited so operators can count real events
    across the netdev lifetime.

The v2 patch 2 IMR-barrier form has been running in production on a
24-node Raspberry Pi 5 fleet since 2026-05-14; ~190 cumulative
node-hours so far, zero mid-runtime TX stalls, zero user-space
watchdog RECOVER events.  Pre-patch baseline (~0.5 stall/node-hour
at fleet level) would have predicted ~95 mid-runtime stalls in that
window; observed is 0.

Related:

  * netdev v1 RFC thread:    https://lore.kernel.org/netdev/cover.1777064117.git.lukasz@raczylo.com/T/
  * netdev v2 series:        https://lore.kernel.org/netdev/20260514215459.36109-1-lukasz@raczylo.com/T/
  * raspberrypi/linux merge: raspberrypi/linux#7340
  * raspberrypi/linux v2 PR: raspberrypi/linux#7369

Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>

Author: lukaszraczylo

kernel/build/patches/0001-net-macb-flush-PCIe-posted-write-after-TSTART-doorbe.patch

@@ -1,81 +1,105 @@
-From 3106d546d494f2f52ec832e7f7d04f534286e254 Mon Sep 17 00:00:00 2001
-Message-ID: <3106d546d494f2f52ec832e7f7d04f534286e254.1777064117.git.lukasz@raczylo.com>
-In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
-References: <cover.1777064117.git.lukasz@raczylo.com>
+From 1c89250b1211cdaa0368dab15686252af6c94a3f Mon Sep 17 00:00:00 2001
 From: Lukasz Raczylo <lukasz@raczylo.com>
-Date: Fri, 24 Apr 2026 21:50:55 +0100
-Subject: [RFC PATCH net-next 1/3] net: macb: flush PCIe posted write after
- TSTART doorbell
+Date: Thu, 14 May 2026 13:24:48 +0100
+Subject: [PATCH net-next v2 1/3] net: macb: flush PCIe posted write after
+ TSTART doorbell (PCIe-only)
 
 macb_start_xmit() and macb_tx_restart() kick transmission by
-OR-ing MACB_BIT(TSTART) into NCR.  On PCIe-attached macb instances
-(BCM2712 + RP1 PCIe south bridge on Raspberry Pi 5 is the setup we
-have in front of us), writes to NCR are posted PCIe writes: they
-are not guaranteed to reach the device before the issuing CPU
-returns.  If the TSTART doorbell does not reach the MAC, no TX
-begins, no TCOMP completion arrives, and the ring remains
-quiescent without any kernel-visible indication.
+OR-ing MACB_BIT(TSTART) into NCR.  On PCIe-attached macb
+instances (BCM2712 + RP1 PCIe south bridge on Raspberry Pi 5 is
+the case I have in front of me), writes to NCR are posted PCIe
+writes: they are not guaranteed to reach the device before the
+issuing CPU returns.  If the TSTART doorbell does not reach the
+MAC, no TX begins, no TCOMP completion arrives, and the ring
+remains quiescent without any kernel-visible indication.
 
-Note that the raspberrypi/linux vendor fork carries a local patch
-around the TSTART site (a queue->tx_pending breadcrumb that is
-promoted to queue->txubr_pending by the next TCOMP interrupt,
-triggering macb_tx_restart()).  That workaround makes the loss
-recoverable under traffic, but it cannot help if TCOMP itself is
-not raised because no TX started -- which is exactly the case we
-are targeting here.  The handshake is not present in mainline.
+Add a read-back of NCR after each TSTART write.  The read is an
+architected PCIe read barrier for earlier posted writes on the
+same path; it ensures the doorbell has reached the MAC before
+the function returns.  As a side effect on macb_start_xmit() it
+also flushes the preceding macb_tx_lpi_wake() NCR write -- not
+just TSTART -- since the barrier applies to all prior posted
+writes by the same requester.
 
-Add a read-back of NCR after each TSTART write in macb_start_xmit()
-and macb_tx_restart().  The read is an architected PCIe read
-barrier for earlier posted writes on the same path; it ensures the
-doorbell has reached the MAC before the functions return.
+The cost is one non-posted PCIe read per TSTART.  To avoid
+imposing this on SoC-integrated macb variants (Atmel, Microchip,
+SiFive, Xilinx), where NCR is on-chip MMIO and no fabric
+posted-write concern exists, gate the readback behind a new
+MACB_CAPS_PCIE_POSTED_WRITES capability set only on
+raspberrypi_rp1_config.
 
-We do not yet have direct hardware evidence that TSTART is being
-lost on the RP1 path (that would require a PCIe protocol analyser,
-or at minimum a before/after counter on queue->tx_stall_last_tail
-with and without this patch applied in isolation).  This patch is
-one of a three-patch series ("candidate fixes for silent TX stall
-on BCM2712/RP1"); see the cover letter for context.  We have
-verified the series compiles and applies cleanly against mainline
-HEAD and against raspberrypi/linux rpi-6.18.y @ f2f68e79f16f;
-runtime verification is pending.
+Note that the raspberrypi/linux vendor fork carries a local
+patch around the TSTART site (a queue->tx_pending breadcrumb
+that is promoted to queue->txubr_pending by the next TCOMP
+interrupt, triggering macb_tx_restart()).  That workaround makes
+the loss recoverable under traffic, but it cannot help if TCOMP
+itself is not raised because no TX started -- which is exactly
+the case targeted here.  The handshake is not present in
+mainline.
 
 Link: https://github.com/cilium/cilium/issues/43198
 Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
 Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
 ---
- drivers/net/ethernet/cadence/macb_main.c | 12 ++++++++++++
- 1 file changed, 12 insertions(+)
+ drivers/net/ethernet/cadence/macb.h      |  4 ++++
+ drivers/net/ethernet/cadence/macb_main.c | 15 +++++++++++++++
+ 2 files changed, 19 insertions(+)
 
+diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
+index 2de56017e..ce9037f9e 100644
+--- a/drivers/net/ethernet/cadence/macb.h
++++ b/drivers/net/ethernet/cadence/macb.h
+@@ -791,6 +791,10 @@
+ #define MACB_CAPS_USRIO_HAS_MII			BIT(26)
+ #define MACB_CAPS_USRIO_HAS_REFCLK_SOURCE	BIT(27)
+ #define MACB_CAPS_USRIO_HAS_TSUCLK_SOURCE	BIT(28)
++/* Register writes are posted on the parent fabric and need a non-posted
++ * read-back to guarantee delivery.  Currently set only on RP1.
++ */
++#define MACB_CAPS_PCIE_POSTED_WRITES		BIT(29)
+ 
+ /* LSO settings */
+ #define MACB_LSO_UFO_ENABLE			0x01
 diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
-index a12aa2124..b6cca55ad 100644
+index a12aa2124..6879f3458 100644
 --- a/drivers/net/ethernet/cadence/macb_main.c
 +++ b/drivers/net/ethernet/cadence/macb_main.c
-@@ -1922,6 +1922,13 @@ static void macb_tx_restart(struct macb_queue *queue)
+@@ -1922,6 +1922,14 @@ static void macb_tx_restart(struct macb_queue *queue)
 
  	spin_lock(&bp->lock);
  	macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
 +	/*
-+	 * Flush the PCIe posted-write queue so the TSTART doorbell
-+	 * reliably reaches the MAC.  Without this, the write can sit
-+	 * in the fabric and the MAC never advances, causing a silent
-+	 * TX stall.
++	 * On PCIe-attached parts, flush the posted-write queue so the
++	 * TSTART doorbell reliably reaches the MAC.  Without this the
++	 * write can sit in the fabric and the MAC never advances,
++	 * causing a silent TX stall.
 +	 */
-+	(void)macb_readl(bp, NCR);
++	if (bp->caps & MACB_CAPS_PCIE_POSTED_WRITES)
++		(void)macb_readl(bp, NCR);
  	spin_unlock(&bp->lock);
 
  out_tx_ptr_unlock:
-@@ -2560,6 +2567,11 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
+@@ -2560,6 +2568,12 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
  	spin_lock(&bp->lock);
  	macb_tx_lpi_wake(bp);
  	macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
 +	/*
-+	 * Flush the PCIe posted-write queue; see the comment in
-+	 * macb_tx_restart() for the reasoning.
++	 * Flush PCIe posted-write queue; see comment in macb_tx_restart().
++	 * Also flushes the preceding macb_tx_lpi_wake() NCR write.
 +	 */
-+	(void)macb_readl(bp, NCR);
++	if (bp->caps & MACB_CAPS_PCIE_POSTED_WRITES)
++		(void)macb_readl(bp, NCR);
  	spin_unlock(&bp->lock);
 
  	if (CIRC_SPACE(queue->tx_head, queue->tx_tail, bp->tx_ring_size) < 1)
+@@ -5674,6 +5688,7 @@ static const struct macb_config raspberrypi_rp1_config = {
+ 	.caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_CLK_HW_CHG |
+ 		MACB_CAPS_JUMBO |
+ 		MACB_CAPS_GEM_HAS_PTP |
++		MACB_CAPS_PCIE_POSTED_WRITES |
+ 		MACB_CAPS_EEE |
+ 		MACB_CAPS_USRIO_HAS_MII,
+ 	.dma_burst_length = 16,
 -- 
-2.53.0
+2.54.0
 

kernel/build/patches/0002-net-macb-insert-PCIe-read-barrier-before-TX-completi.patch

@@ -0,0 +1,66 @@
+From 3d14f2380e6b568f0fe5a9a9a0b5351aea50af3c Mon Sep 17 00:00:00 2001
+From: Lukasz Raczylo <lukasz@raczylo.com>
+Date: Thu, 14 May 2026 13:25:25 +0100
+Subject: [PATCH net-next v2 2/3] net: macb: insert PCIe read barrier before TX
+ completion descriptor check
+
+macb_tx_poll() runs with TCOMP masked, drains the TX ring, then
+calls napi_complete_done() and re-enables TCOMP via IER.  An
+existing comment in the function notes that completions raised
+while TCOMP is masked do not re-fire on IER re-enable, and
+mitigates this by calling macb_tx_complete_pending(), which
+inspects driver-visible ring state (descriptor->ctrl, after
+rmb()) and reschedules NAPI if a completion is observable in
+memory.
+
+On PCIe-attached parts (BCM2712 + RP1 PCIe south bridge on
+Raspberry Pi 5 is the case I have in front of me), the
+descriptor DMA write that sets TX_USED may not have retired to
+system memory at the point macb_tx_complete_pending() runs.  The
+rmb() synchronises the CPU view of earlier CPU writes; it is
+not sufficient to retire an in-flight peripheral DMA write.
+Under that ordering the in-memory descriptor can still read
+TX_USED=0 when the hardware has in fact completed the frame;
+the check returns false; NAPI exits; the quirk above prevents
+the re-enabled IER from re-firing; the ring goes quiescent.
+
+Add a side-effect-free MMIO read between the IER write and the
+macb_tx_complete_pending() check.  The read functions as an
+architected PCIe read barrier for earlier peripheral-originated
+DMA writes on the same path, so any in-flight TX_USED update
+retires to system memory before the descriptor read.
+
+The register chosen is IMR (the read-only interrupt mask
+mirror); reading it has no side effects on either read-clear or
+W1C ISR silicon (it is not the ISR), and the read still flushes
+prior DMA writes via the PCIe completion-ordering guarantee.
+
+Link: https://github.com/cilium/cilium/issues/43198
+Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
+Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
+---
+ drivers/net/ethernet/cadence/macb_main.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
+index 6879f3458..f7fa9e7ad 100644
+--- a/drivers/net/ethernet/cadence/macb_main.c
++++ b/drivers/net/ethernet/cadence/macb_main.c
+@@ -1984,6 +1984,14 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
+ 		 * actions if an interrupt is raised just after enabling them,
+ 		 * but this should be harmless.
+ 		 */
++		/*
++		 * PCIe read barrier: flush any in-flight peripheral DMA
++		 * writes (descriptor TX_USED updates) so the subsequent
++		 * macb_tx_complete_pending() check observes them.  IMR is
++		 * the read-only interrupt mask mirror; the read has no
++		 * side effects on either read-clear or W1C ISR silicon.
++		 */
++		(void)queue_readl(queue, IMR);
+ 		if (macb_tx_complete_pending(queue)) {
+ 			queue_writel(queue, IDR, MACB_BIT(TCOMP));
+ 			macb_queue_isr_clear(bp, queue, MACB_BIT(TCOMP));
+-- 
+2.54.0
+