[PATCH net-next 0/2] net: fec: support RX flushing via fsl,rx-flush-queues

[PATCH net-next 0/2] net: fec: support RX flushing via fsl,rx-flush-queues

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

The FEC/ENET controller can flush frames that get stuck at the head of the
RX FIFO because their destination ring has no empty buffer descriptor
(RxBD[E] clear or ENET_RDARn not set). Without flushing, such a frame blocks
the FIFO and stalls reception on all queues; with flushing enabled the
offending frame is discarded instead. Flushing is configured per RX queue
through the RX_FLUSHn bits of the QOS Scheme register (FEC_QOS_SCHEME).

This series adds a device tree property, fsl,rx-flush-queues, listing the RX
queues for which flushing should be enabled, and programs the corresponding
RX_FLUSHn bits.

Erratum ERR050395 (e.g. i.MX8QXP) can lock up the RX path when flushing is
enabled on more than one queue at the same time; recovery requires a full
ENET reset. Rather than encoding that hardware limitation in the binding,
the DT property is kept generic and the single-queue restriction is enforced
in the driver: a configuration enabling flushing on multiple queues is
rejected unless the controller advertises FEC_QUIRK_HAS_MULTI_RX_FLUSH.
Future parts with the erratum fixed can set that quirk to allow flushing on
several queues.

Example:

    &fec {
        fsl,num-rx-queues = <3>;
        fsl,rx-flush-queues = <1>;
    };

Alexander Sverdlin (2):
  dt-bindings: net: fsl,fec: add fsl,rx-flush-queues
  net: fec: support receive flushing via fsl,rx-flush-queues

 .../devicetree/bindings/net/fsl,fec.yaml      | 14 ++++++++
 drivers/net/ethernet/freescale/fec.h          | 14 ++++++++
 drivers/net/ethernet/freescale/fec_main.c     | 34 +++++++++++++++++++
 3 files changed, 63 insertions(+)

-- 
2.55.0

[PATCH net-next 1/2] dt-bindings: net: fsl,fec: add fsl,rx-flush-queues

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

The FEC/ENET controller can enable receive flushing per RX queue via the
QOS Scheme register (RX_FLUSHn bits). When enabled, a frame at the head of
the RX FIFO that cannot be forwarded (because its ring has no empty buffer
descriptor) is discarded instead of blocking the FIFO.

Add the fsl,rx-flush-queues property to describe the set of RX queues for
which flushing is enabled. Most controllers are subject to erratum
ERR050395 and support flushing on a single queue only; the driver enforces
that constraint, so keep the binding generic to allow future controllers
with the erratum fixed to enable flushing on several queues.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
 .../devicetree/bindings/net/fsl,fec.yaml          | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml
index 24e863fdbdab0..808aaf3fd9f27 100644
--- a/Documentation/devicetree/bindings/net/fsl,fec.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml
@@ -162,6 +162,20 @@ properties:
       Should specify the rx queue number, otherwise set rx queue number to 1.
     enum: [1, 2, 3]
 
+  fsl,rx-flush-queues:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 3
+    items:
+      enum: [0, 1, 2]
+    description:
+      List of RX queue indices for which the receive flushing feature (QOS
+      Scheme register RX_FLUSHn) is enabled. When enabled, a frame at the head
+      of the RX FIFO that cannot be forwarded (because its ring has no empty
+      buffer descriptor) is discarded instead of blocking the FIFO. On most
+      controllers erratum ERR050395 restricts flushing to a single queue. If
+      absent, RX flushing is disabled for all queues.
+
   fsl,magic-packet:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.55.0

[PATCH net-next 2/2] net: fec: support receive flushing via fsl,rx-flush-queues

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

The FEC/ENET controller can flush frames stuck at the head of the RX FIFO
when their destination ring has no empty buffer descriptor, instead of
letting them block the FIFO. This is controlled per RX queue through the
RX_FLUSHn bits of the QOS Scheme register (FEC_QOS_SCHEME).

Parse the new fsl,rx-flush-queues property, build the RX flush mask and
program it in fec_enet_enable_ring().

Erratum ERR050395 (e.g. i.MX8QXP) can cause an RX path lock-up when
flushing is enabled on more than one queue at a time. Rather than encoding
that limitation in the binding, enforce it in the driver: reject a
configuration that enables flushing on multiple queues unless the
controller advertises FEC_QUIRK_HAS_MULTI_RX_FLUSH, which future parts with
the erratum fixed can set.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
 drivers/net/ethernet/freescale/fec.h      | 14 ++++++++++
 drivers/net/ethernet/freescale/fec_main.c | 34 +++++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 7176803146f3d..4af3ae286895f 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -186,6 +186,7 @@
 #define FEC_RCMR_2		0xfff
 #define FEC_DMA_CFG_1		0xfff
 #define FEC_DMA_CFG_2		0xfff
+#define FEC_QOS_SCHEME		0xfff
 #define FEC_TXIC0		0xfff
 #define FEC_TXIC1		0xfff
 #define FEC_TXIC2		0xfff
@@ -322,6 +323,10 @@ struct bufdesc_ex {
 #define RCMR_CMP(X)		(((X) == 1) ? RCMR_CMP_1 : RCMR_CMP_2)
 #define FEC_TX_BD_FTYPE(X)	(((X) & 0xf) << 20)
 
+/* FEC_QOS_SCHEME bits */
+#define QOS_RX_FLUSH(X)		(1 << (3 + (X)))	/* RX_FLUSHn, n = 0, 1, 2 */
+#define QOS_RX_FLUSH_MASK	(QOS_RX_FLUSH(0) | QOS_RX_FLUSH(1) | QOS_RX_FLUSH(2))
+
 /* The number of Tx and Rx buffers.  These are allocated from the page
  * pool.  The code may assume these are power of two, so it is best
  * to keep them that size.
@@ -499,6 +504,12 @@ struct bufdesc_ex {
 /* Jumbo Frame support */
 #define FEC_QUIRK_JUMBO_FRAME		BIT(25)
 
+/* Receive flushing (QOS Scheme register RX_FLUSHn) may be enabled on more than
+ * one RX queue at a time. Parts without this quirk are subject to erratum
+ * ERR050395 and must limit RX flushing to a single queue.
+ */
+#define FEC_QUIRK_HAS_MULTI_RX_FLUSH	BIT(24)
+
 struct bufdesc_prop {
 	int qid;
 	/* Address of Rx and Tx buffers */
@@ -604,6 +615,9 @@ struct fec_enet_private {
 	unsigned int num_tx_queues;
 	unsigned int num_rx_queues;
 
+	/* Bitmask of RX queues with receive flushing enabled */
+	u32 rx_flush_mask;
+
 	struct fec_enet_priv_tx_q *tx_queue[FEC_ENET_MAX_TX_QS];
 	struct fec_enet_priv_rx_q *rx_queue[FEC_ENET_MAX_RX_QS];
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index ced4dbf8cd90f..a4fe8423630b5 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1090,6 +1090,15 @@ static void fec_enet_enable_ring(struct net_device *ndev)
 			       fep->hwp + FEC_RCMR(i));
 	}
 
+	/* Enable receive flushing for the selected queues */
+	if (fep->rx_flush_mask) {
+		u32 val = readl(fep->hwp + FEC_QOS_SCHEME);
+
+		val &= ~QOS_RX_FLUSH_MASK;
+		val |= fep->rx_flush_mask;
+		writel(val, fep->hwp + FEC_QOS_SCHEME);
+	}
+
 	for (i = 0; i < fep->num_tx_queues; i++) {
 		txq = fep->tx_queue[i];
 		writel(txq->bd.dma, fep->hwp + FEC_X_DES_START(i));
@@ -5239,6 +5248,31 @@ fec_probe(struct platform_device *pdev)
 	fep->num_rx_queues = num_rx_qs;
 	fep->num_tx_queues = num_tx_qs;
 
+	/* Enable receive flushing on the requested queues. Erratum ERR050395
+	 * restricts flushing to a single queue; only accept more than one queue
+	 * on controllers known to have the erratum fixed.
+	 */
+	for (i = 0; i < of_property_count_u32_elems(np, "fsl,rx-flush-queues"); i++) {
+		u32 q;
+
+		if (of_property_read_u32_index(np, "fsl,rx-flush-queues", i, &q))
+			break;
+		if (q >= num_rx_qs) {
+			dev_warn(&pdev->dev,
+				 "fsl,rx-flush-queues: queue %u exceeds num-rx-queues, ignoring\n",
+				 q);
+			continue;
+		}
+		fep->rx_flush_mask |= QOS_RX_FLUSH(q);
+	}
+	if (hweight32(fep->rx_flush_mask) > 1 &&
+	    !(fep->quirks & FEC_QUIRK_HAS_MULTI_RX_FLUSH)) {
+		dev_err(&pdev->dev,
+			"fsl,rx-flush-queues: RX flush on multiple queues not supported\n");
+		ret = -EINVAL;
+		goto failed_ioremap;
+	}
+
 	/* default enable pause frame auto negotiation */
 	if (fep->quirks & FEC_QUIRK_HAS_GBIT)
 		fep->pause_flag |= FEC_PAUSE_FLAG_AUTONEG;
-- 
2.55.0

Re: [PATCH net-next 2/2] net: fec: support receive flushing via fsl,rx-flush-queues

[Sverdlin, Alexander]

Hi all,

On Fri, 2026-08-14 at 11:09 +0200, A. Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> The FEC/ENET controller can flush frames stuck at the head of the RX FIFO
> when their destination ring has no empty buffer descriptor, instead of
> letting them block the FIFO. This is controlled per RX queue through the
> RX_FLUSHn bits of the QOS Scheme register (FEC_QOS_SCHEME).
> 
> Parse the new fsl,rx-flush-queues property, build the RX flush mask and
> program it in fec_enet_enable_ring().
> 
> Erratum ERR050395 (e.g. i.MX8QXP) can cause an RX path lock-up when
> flushing is enabled on more than one queue at a time. Rather than encoding
> that limitation in the binding, enforce it in the driver: reject a
> configuration that enables flushing on multiple queues unless the
> controller advertises FEC_QUIRK_HAS_MULTI_RX_FLUSH, which future parts with
> the erratum fixed can set.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
>  drivers/net/ethernet/freescale/fec.h      | 14 ++++++++++
>  drivers/net/ethernet/freescale/fec_main.c | 34 +++++++++++++++++++++++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
> index 7176803146f3d..4af3ae286895f 100644
> --- a/drivers/net/ethernet/freescale/fec.h
> +++ b/drivers/net/ethernet/freescale/fec.h
> @@ -499,6 +504,12 @@ struct bufdesc_ex {
>  /* Jumbo Frame support */
>  #define FEC_QUIRK_JUMBO_FRAME		BIT(25)
>  
> +/* Receive flushing (QOS Scheme register RX_FLUSHn) may be enabled on more than
> + * one RX queue at a time. Parts without this quirk are subject to erratum
> + * ERR050395 and must limit RX flushing to a single queue.
> + */
> +#define FEC_QUIRK_HAS_MULTI_RX_FLUSH	BIT(24)
                                            ^^
This of course should have been "26" (rebasing artifact :( )
Will fix it in v2

> +
>  struct bufdesc_prop {
>  	int qid;
>  	/* Address of Rx and Tx buffers */

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH net-next 0/2] net: fec: support RX flushing via fsl,rx-flush-queues

[Andrew Lunn]

On Fri, Aug 14, 2026 at 11:08:59AM +0200, A. Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> The FEC/ENET controller can flush frames that get stuck at the head of the
> RX FIFO because their destination ring has no empty buffer descriptor
> (RxBD[E] clear or ENET_RDARn not set). Without flushing, such a frame blocks
> the FIFO and stalls reception on all queues; with flushing enabled the
> offending frame is discarded instead. Flushing is configured per RX queue
> through the RX_FLUSHn bits of the QOS Scheme register (FEC_QOS_SCHEME).
> 
> This series adds a device tree property, fsl,rx-flush-queues, listing the RX
> queues for which flushing should be enabled, and programs the corresponding
> RX_FLUSHn bits.

DT described hardware, not policy for how hardware is configured.

Maybe use an ethtool private flags?

> Erratum ERR050395 (e.g. i.MX8QXP) can lock up the RX path when flushing is
> enabled on more than one queue at the same time; recovery requires a full
> ENET reset. Rather than encoding that hardware limitation in the binding,
> the DT property is kept generic and the single-queue restriction is enforced
> in the driver: a configuration enabling flushing on multiple queues is
> rejected unless the controller advertises FEC_QUIRK_HAS_MULTI_RX_FLUSH.
> Future parts with the erratum fixed can set that quirk to allow flushing on
> several queues.

We generally avoid adding features without users. I would suggest
leaving FEC_QUIRK_HAS_MULTI_RX_FLUSH until such hardware exists.


    Andrew

---
pw-bot: cr

Re: [PATCH net-next 0/2] net: fec: support RX flushing via fsl,rx-flush-queues

[Sverdlin, Alexander]

Thanks for the quick feedback, Andrew!

On Fri, 2026-08-14 at 15:56 +0200, Andrew Lunn wrote:
> > The FEC/ENET controller can flush frames that get stuck at the head of the
> > RX FIFO because their destination ring has no empty buffer descriptor
> > (RxBD[E] clear or ENET_RDARn not set). Without flushing, such a frame blocks
> > the FIFO and stalls reception on all queues; with flushing enabled the
> > offending frame is discarded instead. Flushing is configured per RX queue
> > through the RX_FLUSHn bits of the QOS Scheme register (FEC_QOS_SCHEME).
> > 
> > This series adds a device tree property, fsl,rx-flush-queues, listing the RX
> > queues for which flushing should be enabled, and programs the corresponding
> > RX_FLUSHn bits.
> 
> DT described hardware, not policy for how hardware is configured.
> 
> Maybe use an ethtool private flags?

Makes sense to me, I'll rework!

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH net-next 2/2] net: fec: support receive flushing via fsl,rx-flush-queues

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The driver fails to clear bootloader-configured RX flush settings when `fsl,rx-flush-queues` is not specified, potentially inheriting a vulnerable hardware state.
- [High] The newly introduced `FEC_QUIRK_HAS_MULTI_RX_FLUSH` collides with the existing `FEC_QUIRK_HAS_MDIO_C45` bitmask, defeating the ERR050395 erratum safety check.
--

--- Patch [2]: [PATCH net-next 2/2] net: fec: support receive flushing via fsl,rx-flush-queues ---
commit ccf669baa787206c1aada126a00677e049b4714b
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>

net: fec: support receive flushing via fsl,rx-flush-queues

This commit adds support for flushing frames stuck at the head of the RX FIFO
via the FEC_QOS_SCHEME register. It parses the fsl,rx-flush-queues device tree
property and ensures erratum ERR050395 is respected by restricting multi-queue
flushes to hardware that advertises support.

> diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
> index 7176803146f3d..4af3ae286895f 100644
> --- a/drivers/net/ethernet/freescale/fec.h
> +++ b/drivers/net/ethernet/freescale/fec.h
[ ... ]
> @@ -499,6 +504,12 @@ struct bufdesc_ex {
>  /* Jumbo Frame support */
>  #define FEC_QUIRK_JUMBO_FRAME		BIT(25)
>  
> +/* Receive flushing (QOS Scheme register RX_FLUSHn) may be enabled on more than
> + * one RX queue at a time. Parts without this quirk are subject to erratum
> + * ERR050395 and must limit RX flushing to a single queue.
> + */
> +#define FEC_QUIRK_HAS_MULTI_RX_FLUSH	BIT(24)

[Severity: High]
Does this new quirk collide with an existing one?

It appears FEC_QUIRK_HAS_MDIO_C45 is already defined as BIT(24) in this
header file (though outside the context of this patch).

Because of this collision, controllers with MDIO C45 support will mistakenly
evaluate as having the multi-rx-flush quirk, completely bypassing the erratum
safety check added in fec_probe() and allowing lock-ups on vulnerable
hardware.

> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index ced4dbf8cd90f..a4fe8423630b5 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
[ ... ]
> @@ -1090,6 +1090,15 @@ static void fec_enet_enable_ring(struct net_device *ndev)
>  			       fep->hwp + FEC_RCMR(i));
>  	}
>  
> +	/* Enable receive flushing for the selected queues */
> +	if (fep->rx_flush_mask) {
> +		u32 val = readl(fep->hwp + FEC_QOS_SCHEME);
> +
> +		val &= ~QOS_RX_FLUSH_MASK;
> +		val |= fep->rx_flush_mask;
> +		writel(val, fep->hwp + FEC_QOS_SCHEME);
> +	}

[Severity: High]
Can this leave vulnerable bootloader configurations active if the device tree
omits the fsl,rx-flush-queues property?

If fep->rx_flush_mask is 0, this register update is skipped entirely.
Meanwhile, controllers with FEC_QUIRK_HAS_MULTI_QUEUES skip the hardware
reset in fec_ctrl_reset().

If a bootloader (or prior kernel via kexec) enabled RX flushing on multiple
queues, and the current device tree doesn't specify the property, the old
configuration will persist. This could inherit a dangerous hardware state
and trigger the ERR050395 RX path lock-up.

Should the FEC_QOS_SCHEME register always be updated to clear the mask if
fep->rx_flush_mask is 0?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260814090906.2225075-1-alexander.sverdlin@siemens.com?part=2