AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the Freescale Fast Ethernet Controller (FEC) driver, which is a hardware-specific SoC peripheral for NXP/Freescale i.MX and Vybrid families. As a platform device, it cannot be instantiated or reached in standard virtualized environments (e.g., QEMU 'virt' or 'q35' machines) used for fuzzing.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 2cc7c74be689bb1c7efaac1bcdcc8ec02b73aa53\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 25 10:09:30 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/Documentation/networking/device_drivers/ethernet/freescale/fec.rst b/Documentation/networking/device_drivers/ethernet/freescale/fec.rst\nnew file mode 100644\nindex 0000000000000..502261f517e05\n--- /dev/null\n+++ b/Documentation/networking/device_drivers/ethernet/freescale/fec.rst\n@@ -0,0 +1,55 @@\n+.. SPDX-License-Identifier: GPL-2.0\n+\n+========================================\n+Freescale Fast Ethernet Controller (FEC)\n+========================================\n+\n+The Fast Ethernet Controller (FEC), also known as ENET, is the Ethernet MAC\n+found on many Freescale/NXP SoCs, including the i.MX and Vybrid families. This\n+document describes driver-specific configuration that is not covered by the\n+generic networking documentation.\n+\n+Ethtool private flags\n+======================\n+\n+Some hardware features that are specific to the FEC and have no generic ethtool\n+control are exposed as ethtool private flags. The set of available flags depends\n+on the SoC and on the driver configuration (for example, the number of receive\n+queues), so the flags are enumerated at runtime::\n+\n+\t$ ethtool --show-priv-flags ethX\n+\n+\t$ ethtool --set-priv-flags ethX \u003cflag\u003e on|off\n+\n+rx-flush-qN\n+-----------\n+\n+On multi-queue capable controllers the driver exposes one ``rx-flush-qN``\n+private flag per receive queue (``rx-flush-q0``, ``rx-flush-q1``, ...), which\n+enables RX flushing for that queue. RX flushing is disabled by default.\n+\n+The controller uses a single RX FIFO that is shared by all receive queues. A\n+received frame is only removed from the head of the FIFO once it has been\n+copied into the buffer descriptor ring of the queue it is destined for. If that\n+ring cannot currently accept the frame - i.e. its next buffer descriptor is not\n+marked empty (``RxBD[EMPTY]`` is clear) or the ring has not been (re)activated\n+(``ENET_RDARn`` is clear) - the frame stays at the head of the FIFO and blocks\n+all subsequent frames, including those destined for other, non-congested queues.\n+\n+When RX flushing is enabled for a queue, a frame that would otherwise block the\n+FIFO in this way is instead discarded (flushed), so that frames for the other\n+queues can keep flowing. This is controlled through the ``RX_FLUSHn`` bits of\n+the ``FEC_QOS_SCHEME`` (``ENET_QOS``) register; see the \"Receive flush\" and\n+\"ENET_QOS field descriptions\" sections of the SoC reference manual (for example\n+the i.MX 8DualX/8DualXPlus/8QuadXPlus Applications Processor Reference Manual,\n+IMX8DQXPRM).\n+\n+.. note::\n+\n+   Due to erratum ERR050395 (see the applicable Mask Set Errata document, e.g.\n+   IMX8X_0N99Z for the i.MX 8QuadXPlus), enabling RX flushing on more than one\n+   receive queue at a time can, under certain traffic conditions, lock up the\n+   receive path instead of flushing the blocking frame. To avoid triggering the\n+   erratum the driver rejects (with ``-EINVAL``) any attempt to enable\n+   ``rx-flush-qN`` on more than one queue simultaneously; only a single queue\n+   may have RX flushing enabled.\ndiff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst\nindex d9980c84487a5..0a304b158ef70 100644\n--- a/Documentation/networking/device_drivers/ethernet/index.rst\n+++ b/Documentation/networking/device_drivers/ethernet/index.rst\n@@ -24,6 +24,7 @@ Contents:\n    dec/dmfe\n    freescale/dpaa\n    freescale/dpaa2/index\n+   freescale/fec\n    freescale/gianfar\n    google/gve\n    huawei/hinic\ndiff --git a/MAINTAINERS b/MAINTAINERS\nindex 460cb72688450..80e412c1283c7 100644\n--- a/MAINTAINERS\n+++ b/MAINTAINERS\n@@ -10375,6 +10375,7 @@ L:\timx@lists.linux.dev\n L:\tnetdev@vger.kernel.org\n S:\tMaintained\n F:\tDocumentation/devicetree/bindings/net/fsl,fec.yaml\n+F:\tDocumentation/networking/device_drivers/ethernet/freescale/fec.rst\n F:\tdrivers/net/ethernet/freescale/fec.h\n F:\tdrivers/net/ethernet/freescale/fec_main.c\n F:\tdrivers/net/ethernet/freescale/fec_ptp.c\ndiff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h\nindex 7176803146f3d..f3dbad8db769f 100644\n--- a/drivers/net/ethernet/freescale/fec.h\n+++ b/drivers/net/ethernet/freescale/fec.h\n@@ -322,6 +322,10 @@ struct bufdesc_ex {\n #define RCMR_CMP(X)\t\t(((X) == 1) ? RCMR_CMP_1 : RCMR_CMP_2)\n #define FEC_TX_BD_FTYPE(X)\t(((X) \u0026 0xf) \u003c\u003c 20)\n \n+/* FEC_QOS_SCHEME bits */\n+#define QOS_RX_FLUSH(X)\t\tBIT(3 + (X))\n+#define QOS_RX_FLUSH_MASK\t(QOS_RX_FLUSH(0) | QOS_RX_FLUSH(1) | QOS_RX_FLUSH(2))\n+\n /* The number of Tx and Rx buffers.  These are allocated from the page\n  * pool.  The code may assume these are power of two, so it is best\n  * to keep them that size.\n@@ -604,6 +608,11 @@ struct fec_enet_private {\n \tunsigned int num_tx_queues;\n \tunsigned int num_rx_queues;\n \n+\t/* Bitmask of RX queues with receive flushing enabled */\n+\tu32 rx_flush_mask;\n+\t/* Serializes the FEC_QOS_SCHEME read-modify-write */\n+\tspinlock_t qos_lock;\n+\n \tstruct fec_enet_priv_tx_q *tx_queue[FEC_ENET_MAX_TX_QS];\n \tstruct fec_enet_priv_rx_q *rx_queue[FEC_ENET_MAX_RX_QS];\n \ndiff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c\nindex ced4dbf8cd90f..c45282defb0c3 100644\n--- a/drivers/net/ethernet/freescale/fec_main.c\n+++ b/drivers/net/ethernet/freescale/fec_main.c\n@@ -1072,6 +1072,20 @@ static void fec_enet_active_rxring(struct net_device *ndev)\n \t\twritel(0, fep-\u003erx_queue[i]-\u003ebd.reg_desc_active);\n }\n \n+/* Program the per-queue RX flushing bits in FEC_QOS_SCHEME */\n+static void fec_enet_set_rx_flush(struct fec_enet_private *fep)\n+{\n+#if !defined(CONFIG_M5272)\n+\tu32 val;\n+\n+\t/* ethtool can race with fec_enet_adjust_link() (no RTNL) */\n+\tguard(spinlock)(\u0026fep-\u003eqos_lock);\n+\tval = readl(fep-\u003ehwp + FEC_QOS_SCHEME);\n+\tval \u0026= ~QOS_RX_FLUSH_MASK;\n+\twritel(val | fep-\u003erx_flush_mask, fep-\u003ehwp + FEC_QOS_SCHEME);\n+#endif\n+}\n+\n static void fec_enet_enable_ring(struct net_device *ndev)\n {\n \tstruct fec_enet_private *fep = netdev_priv(ndev);\n@@ -1090,6 +1104,8 @@ static void fec_enet_enable_ring(struct net_device *ndev)\n \t\t\t       fep-\u003ehwp + FEC_RCMR(i));\n \t}\n \n+\tfec_enet_set_rx_flush(fep);\n+\n \tfor (i = 0; i \u003c fep-\u003enum_tx_queues; i++) {\n \t\ttxq = fep-\u003etx_queue[i];\n \t\twritel(txq-\u003ebd.dma, fep-\u003ehwp + FEC_X_DES_START(i));\n@@ -3546,6 +3562,7 @@ static void fec_enet_get_ethtool_stats(struct net_device *dev,\n static void fec_enet_get_strings(struct net_device *netdev,\n \tu32 stringset, u8 *data)\n {\n+\tstruct fec_enet_private *fep = netdev_priv(netdev);\n \tint i;\n \tswitch (stringset) {\n \tcase ETH_SS_STATS:\n@@ -3561,11 +3578,18 @@ static void fec_enet_get_strings(struct net_device *netdev,\n \tcase ETH_SS_TEST:\n \t\tnet_selftest_get_strings(data);\n \t\tbreak;\n+\tcase ETH_SS_PRIV_FLAGS:\n+\t\tfor (i = 0; i \u003c fep-\u003enum_rx_queues; i++) {\n+\t\t\tsnprintf(data, ETH_GSTRING_LEN, \"rx-flush-q%d\", i);\n+\t\t\tdata += ETH_GSTRING_LEN;\n+\t\t}\n+\t\tbreak;\n \t}\n }\n \n static int fec_enet_get_sset_count(struct net_device *dev, int sset)\n {\n+\tstruct fec_enet_private *fep = netdev_priv(dev);\n \tint count;\n \n \tswitch (sset) {\n@@ -3576,11 +3600,58 @@ static int fec_enet_get_sset_count(struct net_device *dev, int sset)\n \n \tcase ETH_SS_TEST:\n \t\treturn net_selftest_get_count();\n+\tcase ETH_SS_PRIV_FLAGS:\n+\t\treturn fep-\u003enum_rx_queues;\n \tdefault:\n \t\treturn -EOPNOTSUPP;\n \t}\n }\n \n+static u32 fec_enet_get_priv_flags(struct net_device *ndev)\n+{\n+\tstruct fec_enet_private *fep = netdev_priv(ndev);\n+\tu32 flags = 0;\n+\tint i;\n+\n+\tfor (i = 0; i \u003c fep-\u003enum_rx_queues; i++)\n+\t\tif (fep-\u003erx_flush_mask \u0026 QOS_RX_FLUSH(i))\n+\t\t\tflags |= BIT(i);\n+\n+\treturn flags;\n+}\n+\n+static int fec_enet_set_priv_flags(struct net_device *ndev, u32 flags)\n+{\n+\tstruct fec_enet_private *fep = netdev_priv(ndev);\n+\tu32 mask = 0;\n+\tint i;\n+\n+\tif (flags \u0026 ~(BIT(fep-\u003enum_rx_queues) - 1))\n+\t\treturn -EINVAL;\n+\n+\t/* Erratum ERR050395 */\n+\tif (hweight32(flags) \u003e 1) {\n+\t\tnetdev_err(ndev, \"RX flush is supported on a single queue only\\n\");\n+\t\treturn -EINVAL;\n+\t}\n+\n+\tfor (i = 0; i \u003c fep-\u003enum_rx_queues; i++)\n+\t\tif (flags \u0026 BIT(i))\n+\t\t\tmask |= QOS_RX_FLUSH(i);\n+\n+\tif (mask == fep-\u003erx_flush_mask)\n+\t\treturn 0;\n+\n+\tfep-\u003erx_flush_mask = mask;\n+\n+\tif (!netif_running(ndev))\n+\t\treturn 0;\n+\n+\tfec_enet_set_rx_flush(fep);\n+\n+\treturn 0;\n+}\n+\n static void fec_enet_clear_ethtool_stats(struct net_device *dev)\n {\n \tstruct fec_enet_private *fep = netdev_priv(dev);\n@@ -3800,6 +3871,8 @@ static const struct ethtool_ops fec_enet_ethtool_ops = {\n \t.get_strings\t\t= fec_enet_get_strings,\n \t.get_ethtool_stats\t= fec_enet_get_ethtool_stats,\n \t.get_sset_count\t\t= fec_enet_get_sset_count,\n+\t.get_priv_flags\t\t= fec_enet_get_priv_flags,\n+\t.set_priv_flags\t\t= fec_enet_set_priv_flags,\n #endif\n \t.get_ts_info\t\t= fec_enet_get_ts_info,\n \t.get_wol\t\t= fec_enet_get_wol,\n@@ -5323,6 +5396,7 @@ fec_probe(struct platform_device *pdev)\n \n \tfep-\u003eptp_clk_on = false;\n \tmutex_init(\u0026fep-\u003eptp_clk_mutex);\n+\tspin_lock_init(\u0026fep-\u003eqos_lock);\n \n \t/* clk_ref is optional, depends on board */\n \tfep-\u003eclk_ref = devm_clk_get_optional(\u0026pdev-\u003edev, \"enet_clk_ref\");\n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Freescale Fast Ethernet Controller (FEC) driver, which is a hardware-specific SoC peripheral for NXP/Freescale i.MX and Vybrid families. As a platform device, it cannot be instantiated or reached in standard virtualized environments (e.g., QEMU 'virt' or 'q35' machines) used for fuzzing.",
  "WorthFuzzing": false
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 2cc7c74be689bb1c7efaac1bcdcc8ec02b73aa53
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 25 10:09:30 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/networking/device_drivers/ethernet/freescale/fec.rst b/Documentation/networking/device_drivers/ethernet/freescale/fec.rst
new file mode 100644
index 0000000000000..502261f517e05
--- /dev/null
+++ b/Documentation/networking/device_drivers/ethernet/freescale/fec.rst
@@ -0,0 +1,55 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Freescale Fast Ethernet Controller (FEC)
+========================================
+
+The Fast Ethernet Controller (FEC), also known as ENET, is the Ethernet MAC
+found on many Freescale/NXP SoCs, including the i.MX and Vybrid families. This
+document describes driver-specific configuration that is not covered by the
+generic networking documentation.
+
+Ethtool private flags
+======================
+
+Some hardware features that are specific to the FEC and have no generic ethtool
+control are exposed as ethtool private flags. The set of available flags depends
+on the SoC and on the driver configuration (for example, the number of receive
+queues), so the flags are enumerated at runtime::
+
+	$ ethtool --show-priv-flags ethX
+
+	$ ethtool --set-priv-flags ethX <flag> on|off
+
+rx-flush-qN
+-----------
+
+On multi-queue capable controllers the driver exposes one ``rx-flush-qN``
+private flag per receive queue (``rx-flush-q0``, ``rx-flush-q1``, ...), which
+enables RX flushing for that queue. RX flushing is disabled by default.
+
+The controller uses a single RX FIFO that is shared by all receive queues. A
+received frame is only removed from the head of the FIFO once it has been
+copied into the buffer descriptor ring of the queue it is destined for. If that
+ring cannot currently accept the frame - i.e. its next buffer descriptor is not
+marked empty (``RxBD[EMPTY]`` is clear) or the ring has not been (re)activated
+(``ENET_RDARn`` is clear) - the frame stays at the head of the FIFO and blocks
+all subsequent frames, including those destined for other, non-congested queues.
+
+When RX flushing is enabled for a queue, a frame that would otherwise block the
+FIFO in this way is instead discarded (flushed), so that frames for the other
+queues can keep flowing. This is controlled through the ``RX_FLUSHn`` bits of
+the ``FEC_QOS_SCHEME`` (``ENET_QOS``) register; see the "Receive flush" and
+"ENET_QOS field descriptions" sections of the SoC reference manual (for example
+the i.MX 8DualX/8DualXPlus/8QuadXPlus Applications Processor Reference Manual,
+IMX8DQXPRM).
+
+.. note::
+
+   Due to erratum ERR050395 (see the applicable Mask Set Errata document, e.g.
+   IMX8X_0N99Z for the i.MX 8QuadXPlus), enabling RX flushing on more than one
+   receive queue at a time can, under certain traffic conditions, lock up the
+   receive path instead of flushing the blocking frame. To avoid triggering the
+   erratum the driver rejects (with ``-EINVAL``) any attempt to enable
+   ``rx-flush-qN`` on more than one queue simultaneously; only a single queue
+   may have RX flushing enabled.
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst
index d9980c84487a5..0a304b158ef70 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -24,6 +24,7 @@ Contents:
    dec/dmfe
    freescale/dpaa
    freescale/dpaa2/index
+   freescale/fec
    freescale/gianfar
    google/gve
    huawei/hinic
diff --git a/MAINTAINERS b/MAINTAINERS
index 460cb72688450..80e412c1283c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10375,6 +10375,7 @@ L:	imx@lists.linux.dev
 L:	netdev@vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/net/fsl,fec.yaml
+F:	Documentation/networking/device_drivers/ethernet/freescale/fec.rst
 F:	drivers/net/ethernet/freescale/fec.h
 F:	drivers/net/ethernet/freescale/fec_main.c
 F:	drivers/net/ethernet/freescale/fec_ptp.c
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 7176803146f3d..f3dbad8db769f 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -322,6 +322,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)		BIT(3 + (X))
+#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.
@@ -604,6 +608,11 @@ 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;
+	/* Serializes the FEC_QOS_SCHEME read-modify-write */
+	spinlock_t qos_lock;
+
 	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..c45282defb0c3 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1072,6 +1072,20 @@ static void fec_enet_active_rxring(struct net_device *ndev)
 		writel(0, fep->rx_queue[i]->bd.reg_desc_active);
 }
 
+/* Program the per-queue RX flushing bits in FEC_QOS_SCHEME */
+static void fec_enet_set_rx_flush(struct fec_enet_private *fep)
+{
+#if !defined(CONFIG_M5272)
+	u32 val;
+
+	/* ethtool can race with fec_enet_adjust_link() (no RTNL) */
+	guard(spinlock)(&fep->qos_lock);
+	val = readl(fep->hwp + FEC_QOS_SCHEME);
+	val &= ~QOS_RX_FLUSH_MASK;
+	writel(val | fep->rx_flush_mask, fep->hwp + FEC_QOS_SCHEME);
+#endif
+}
+
 static void fec_enet_enable_ring(struct net_device *ndev)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
@@ -1090,6 +1104,8 @@ static void fec_enet_enable_ring(struct net_device *ndev)
 			       fep->hwp + FEC_RCMR(i));
 	}
 
+	fec_enet_set_rx_flush(fep);
+
 	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));
@@ -3546,6 +3562,7 @@ static void fec_enet_get_ethtool_stats(struct net_device *dev,
 static void fec_enet_get_strings(struct net_device *netdev,
 	u32 stringset, u8 *data)
 {
+	struct fec_enet_private *fep = netdev_priv(netdev);
 	int i;
 	switch (stringset) {
 	case ETH_SS_STATS:
@@ -3561,11 +3578,18 @@ static void fec_enet_get_strings(struct net_device *netdev,
 	case ETH_SS_TEST:
 		net_selftest_get_strings(data);
 		break;
+	case ETH_SS_PRIV_FLAGS:
+		for (i = 0; i < fep->num_rx_queues; i++) {
+			snprintf(data, ETH_GSTRING_LEN, "rx-flush-q%d", i);
+			data += ETH_GSTRING_LEN;
+		}
+		break;
 	}
 }
 
 static int fec_enet_get_sset_count(struct net_device *dev, int sset)
 {
+	struct fec_enet_private *fep = netdev_priv(dev);
 	int count;
 
 	switch (sset) {
@@ -3576,11 +3600,58 @@ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
 
 	case ETH_SS_TEST:
 		return net_selftest_get_count();
+	case ETH_SS_PRIV_FLAGS:
+		return fep->num_rx_queues;
 	default:
 		return -EOPNOTSUPP;
 	}
 }
 
+static u32 fec_enet_get_priv_flags(struct net_device *ndev)
+{
+	struct fec_enet_private *fep = netdev_priv(ndev);
+	u32 flags = 0;
+	int i;
+
+	for (i = 0; i < fep->num_rx_queues; i++)
+		if (fep->rx_flush_mask & QOS_RX_FLUSH(i))
+			flags |= BIT(i);
+
+	return flags;
+}
+
+static int fec_enet_set_priv_flags(struct net_device *ndev, u32 flags)
+{
+	struct fec_enet_private *fep = netdev_priv(ndev);
+	u32 mask = 0;
+	int i;
+
+	if (flags & ~(BIT(fep->num_rx_queues) - 1))
+		return -EINVAL;
+
+	/* Erratum ERR050395 */
+	if (hweight32(flags) > 1) {
+		netdev_err(ndev, "RX flush is supported on a single queue only\n");
+		return -EINVAL;
+	}
+
+	for (i = 0; i < fep->num_rx_queues; i++)
+		if (flags & BIT(i))
+			mask |= QOS_RX_FLUSH(i);
+
+	if (mask == fep->rx_flush_mask)
+		return 0;
+
+	fep->rx_flush_mask = mask;
+
+	if (!netif_running(ndev))
+		return 0;
+
+	fec_enet_set_rx_flush(fep);
+
+	return 0;
+}
+
 static void fec_enet_clear_ethtool_stats(struct net_device *dev)
 {
 	struct fec_enet_private *fep = netdev_priv(dev);
@@ -3800,6 +3871,8 @@ static const struct ethtool_ops fec_enet_ethtool_ops = {
 	.get_strings		= fec_enet_get_strings,
 	.get_ethtool_stats	= fec_enet_get_ethtool_stats,
 	.get_sset_count		= fec_enet_get_sset_count,
+	.get_priv_flags		= fec_enet_get_priv_flags,
+	.set_priv_flags		= fec_enet_set_priv_flags,
 #endif
 	.get_ts_info		= fec_enet_get_ts_info,
 	.get_wol		= fec_enet_get_wol,
@@ -5323,6 +5396,7 @@ fec_probe(struct platform_device *pdev)
 
 	fep->ptp_clk_on = false;
 	mutex_init(&fep->ptp_clk_mutex);
+	spin_lock_init(&fep->qos_lock);
 
 	/* clk_ref is optional, depends on board */
 	fep->clk_ref = devm_clk_get_optional(&pdev->dev, "enet_clk_ref");

gemini-3.1-pro-preview

null

null

							input: 5336
							output: 24
							thoughts: 982
						

**Fuzzing Feasibility of the Freescale FEC Driver's Private Flags**

Okay, so we have this patch adding ethtool private flags, specifically `rx-flush-qN`, to the Freescale Fast Ethernet Controller (FEC) driver in `drivers/net/ethernet/freescale/fec_main.c`. This modifies several functions: `fec_enet_get_strings`, `fec_enet_get_sset_count`, `fec_enet_get_priv_flags`, `fec_enet_set_priv_flags`, and `fec_enet_set_rx_flush`. This driver is for Freescale/NXP SoCs, the i.MX and Vybrid families.

My initial concern is reachability in standard virtualized environments. This is a *hardware* Ethernet controller, so the question is, does QEMU emulate it?  Let's see... QEMU *does* have `imx.c` and `imx_fec.c`, so there *is* some emulation for it. I need to confirm if `fec_probe` is reachable in the QEMU configuration. The supported boards include `imx25-pdk`, `kzm`, `imx6`, `imx7`, `sabrelite`, `mcimx6ul-evk`, and `mcimx7d-sabre`. These are all ARM-based boards. That's a problem, isn't it? My go-to is x86_64 QEMU or GCE.

However, the instructions state an exception for emulation. Okay, this is a platform driver, `fec_probe` takes a `struct platform_device *pdev`. It matches `fec_dt_ids`. Let's confirm that.

```c
static const struct of_device_id fec_dt_ids[] = {
	{ .compatible = "fsl,imx25-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx6q-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,mvf600-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx6sx-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx6ul-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx8mq-fec", .data = &fec_devtype[0] },
	{ .compatible = "fsl,imx8qm-fec", .data = &fec_devtype[0] },
	{ /* sentinel */ }
};
```

Okay, so it *is* a platform driver and uses device tree.  So, this *is* emulated in QEMU, as evidenced by `hw/net/imx_fec.c`. The challenge is, does Syzkaller *typically* fuzz this? Syzkaller fuzzes primarily `qemu-system-aarch64 -machine virt`, but the `virt` machine doesn't have `fsl,imx...` devices. Could this device be instantiated some other way? No, platform devices are typically defined via Device Tree. Let's see if syzkaller has descriptions for it. Looks like this needs some further investigation.

{
  "Expression": "fec_enet_set_priv_flags"
}

{
  "Output": "drivers/net/ethernet/freescale/fec_main.c=3610=static u32 fec_enet_get_priv_flags(struct net_device *ndev)\n--\ndrivers/net/ethernet/freescale/fec_main.c-3622-\ndrivers/net/ethernet/freescale/fec_main.c:3623:static int fec_enet_set_priv_flags(struct net_device *ndev, u32 flags)\ndrivers/net/ethernet/freescale/fec_main.c-3624-{\n--\ndrivers/net/ethernet/freescale/fec_main.c=3858=static const struct ethtool_ops fec_enet_ethtool_ops = {\n--\ndrivers/net/ethernet/freescale/fec_main.c-3874-\t.get_priv_flags\t\t= fec_enet_get_priv_flags,\ndrivers/net/ethernet/freescale/fec_main.c:3875:\t.set_priv_flags\t\t= fec_enet_set_priv_flags,\ndrivers/net/ethernet/freescale/fec_main.c-3876-#endif\n"
}

gemini-3.1-pro-preview

null

null

							input: 7493
							output: 108
							thoughts: 310
						

**My Assessment of the Freescale FEC Driver's Fuzzing Potential**

Okay, let's take a look at `drivers/net/ethernet/freescale/fec_main.c`. The task is to determine if this code is likely to be reachable during fuzzing. The instructions explicitly warn about unreachable code paths in virtualized environments, even with emulated hardware.

This is a Freescale FEC ethernet controller, a platform device, specifically designed for System-on-a-Chip (SoC) integration. Right away, my experience tells me this is going to be problematic. Unless we're using a very specific ARM QEMU setup, namely with a machine type like `mcimx6ul-evk`, this device simply won't be present. Syzkaller, in its default configurations, leverages `q35` for x86_64 and `virt` for aarch64. Neither of these machine types, the standard for fuzzing, emulates or includes this Freescale FEC.

Just to be absolutely sure, I'll quickly check if there's any conceivable way to instantiate this device on a `virt` or `q35` machine. Nope, it's not a PCI or USB device that could potentially be hotplugged. It's a memory-mapped SoC peripheral, deeply tied to the specific hardware architecture.

Therefore, considering my understanding of the underlying hardware and the standard fuzzing environments, I have to conclude that this code path is effectively unreachable in the standard virtualized setups we use for fuzzing. I'll return `WorthFuzzing=false`, and state the rationale: this is a hardware-specific SoC driver (Freescale FEC) that isn't accessible in typical QEMU setups (like `virt` or `q35`) used for fuzzing.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Freescale Fast Ethernet Controller (FEC) driver, which is a hardware-specific SoC peripheral for NXP/Freescale i.MX and Vybrid families. As a platform device, it cannot be instantiated or reached in standard virtualized environments (e.g., QEMU 'virt' or 'q35' machines) used for fuzzing.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Freescale Fast Ethernet Controller (FEC) driver, which is a hardware-specific SoC peripheral for NXP/Freescale i.MX and Vybrid families. As a platform device, it cannot be instantiated or reached in standard virtualized environments (e.g., QEMU 'virt' or 'q35' machines) used for fuzzing.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null