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

[sashiko-bot@kernel.org]

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