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

[Andrew Lunn <andrew@lunn.ch>]

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