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

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

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