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

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