AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/08/14 06:35	flow	patch-triage	3m Args: null Results: { "EnableConfigs": [ "STMMAC_ETH", "STMMAC_PCI" ], "FocusSymbols": [ "stmmac_dvr_remove", "stmmac_suspend", "stmmac_resume", "stmmac_xdp_open", "stmmac_xdp_release", "stmmac_reinit_queues", "stmmac_reinit_ringparam" ], "KMSANReasoning": "The patch modifies the hardware initialization and teardown sequences in the stmmac driver, introducing an ordered datapath teardown to properly stop DMA and MAC operations. It adds functions to poll hardware registers for specific states (e.g., DMA stopped, MTL queues drained) using `readl_poll_timeout`. These changes are purely related to hardware control flow and do not introduce any new data structures, buffer allocations, or data copies to user space. There is no risk of uninitialized memory being exposed or used in control flow. Standard KASAN and other bug detectors are sufficient to catch any potential memory corruption or use-after-free bugs that might arise from driver teardown issues.", "NeedsKMSAN": false, "Reasoning": "The patch introduces a new ordered datapath teardown sequence for all stmmac devices, changing the order of DMA stop and MAC disable operations. It also swaps the order of MAC enable and DMA start in the setup paths. These are functional changes to the core driver logic reachable via PCI emulation.", "WorthFuzzing": true }
1/1	2026/08/14 06:35	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit a08ff34cb2cd2d29c1e2615dd14480ccb2d870fb\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Fri Aug 14 06:35:32 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h\nindex f8ab347f7b5b9..50f9ccd4a9c46 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h\n+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h\n@@ -291,6 +291,10 @@\n #define XGMAC_TTC\t\t\tGENMASK(6, 4)\n #define XGMAC_TXQEN\t\t\tGENMASK(3, 2)\n #define XGMAC_TSF\t\t\tBIT(1)\n+#define XGMAC_MTL_TXQ_DEBUG(x)\t\t(0x00001108 + (0x80 * (x)))\n+#define XGMAC_TXQSTS\t\t\tBIT(4)\n+#define XGMAC_TRCSTS\t\t\tGENMASK(2, 1)\n+#define XGMAC_TRCSTS_READ\t\t0x1\n #define XGMAC_MTL_TCx_ETS_CONTROL(x)\t(0x00001110 + (0x80 * (x)))\n #define XGMAC_MTL_TCx_QUANTUM_WEIGHT(x)\t(0x00001118 + (0x80 * (x)))\n #define XGMAC_MTL_TCx_SENDSLOPE(x)\t(0x0000111c + (0x80 * (x)))\n@@ -306,6 +310,9 @@\n #define XGMAC_EHFC\t\t\tBIT(7)\n #define XGMAC_RSF\t\t\tBIT(5)\n #define XGMAC_RTC\t\t\tGENMASK(1, 0)\n+#define XGMAC_MTL_RXQ_DEBUG(x)\t\t(0x00001148 + (0x80 * (x)))\n+#define XGMAC_PRXQ\t\t\tGENMASK(29, 16)\n+#define XGMAC_RXQSTS\t\t\tGENMASK(5, 4)\n #define XGMAC_MTL_RXQ_FLOW_CONTROL(x)\t(0x00001150 + (0x80 * (x)))\n #define XGMAC_RFD\t\t\tGENMASK(31, 17)\n #define XGMAC_RFA\t\t\tGENMASK(15, 1)\n@@ -391,6 +398,7 @@\n #define XGMAC_NIS\t\t\tBIT(15)\n #define XGMAC_AIS\t\t\tBIT(14)\n #define XGMAC_FBE\t\t\tBIT(12)\n+#define XGMAC_RPS\t\t\tBIT(8)\n #define XGMAC_RBU\t\t\tBIT(7)\n #define XGMAC_RI\t\t\tBIT(6)\n #define XGMAC_TBU\t\t\tBIT(2)\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c\nindex ff83858ebc1f3..ba4f535fb9eb4 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c\n+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c\n@@ -4,6 +4,7 @@\n * stmmac XGMAC support.\n /\n \n+#include \u003clinux/bitfield.h\u003e\n #include \u003clinux/iopoll.h\u003e\n #include \"stmmac.h\"\n #include \"dwxgmac2.h\"\n@@ -261,13 +262,12 @@ static void dwxgmac2_dma_start_tx(struct stmmac_priv priv,\n {\n \tu32 value;\n \n+\t/* TPS is latched once set, so clear it on every Tx DMA start. /\n+\twritel(XGMAC_TPS, ioaddr + XGMAC_DMA_CH_STATUS(chan));\n+\n \tvalue = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));\n \tvalue \|= XGMAC_TXST;\n \twritel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));\n-\n-\tvalue = readl(ioaddr + XGMAC_TX_CONFIG);\n-\tvalue \|= XGMAC_CONFIG_TE;\n-\twritel(value, ioaddr + XGMAC_TX_CONFIG);\n }\n \n static void dwxgmac2_dma_stop_tx(struct stmmac_priv priv, void __iomem ioaddr,\n@@ -278,10 +278,6 @@ static void dwxgmac2_dma_stop_tx(struct stmmac_priv priv, void __iomem ioaddr,\n \tvalue = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));\n \tvalue \u0026= ~XGMAC_TXST;\n \twritel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));\n-\n-\tvalue = readl(ioaddr + XGMAC_TX_CONFIG);\n-\tvalue \u0026= ~XGMAC_CONFIG_TE;\n-\twritel(value, ioaddr + XGMAC_TX_CONFIG);\n }\n \n static void dwxgmac2_dma_start_rx(struct stmmac_priv priv,\n@@ -289,13 +285,12 @@ static void dwxgmac2_dma_start_rx(struct stmmac_priv priv,\n {\n \tu32 value;\n \n+\t/ RPS is latched once set, so clear it on every Rx DMA start. /\n+\twritel(XGMAC_RPS, ioaddr + XGMAC_DMA_CH_STATUS(chan));\n+\n \tvalue = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));\n \tvalue \|= XGMAC_RXST;\n \twritel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));\n-\n-\tvalue = readl(ioaddr + XGMAC_RX_CONFIG);\n-\tvalue \|= XGMAC_CONFIG_RE;\n-\twritel(value, ioaddr + XGMAC_RX_CONFIG);\n }\n \n static void dwxgmac2_dma_stop_rx(struct stmmac_priv priv, void __iomem ioaddr,\n@@ -592,6 +587,77 @@ static int dwxgmac2_enable_tbs(struct stmmac_priv priv, void __iomem ioaddr,\n \treturn 0;\n }\n \n+static int dwxgmac2_tx_dma_stopped(struct stmmac_priv priv,\n+\t\t\t\t void __iomem ioaddr, u32 chan)\n+{\n+\tu32 value;\n+\tint ret;\n+\n+\tret = readl_poll_timeout(ioaddr + XGMAC_DMA_CH_STATUS(chan), value,\n+\t\t\t\t value \u0026 XGMAC_TPS, 100, 10000);\n+\tif (ret)\n+\t\tnetdev_warn(priv-\u003edev, \"Tx DMA channel %u stop timeout\\n\",\n+\t\t\t chan);\n+\n+\treturn ret;\n+}\n+\n+static int dwxgmac2_tx_mtl_drain(struct stmmac_priv priv,\n+\t\t\t\t void __iomem ioaddr, u32 queue)\n+{\n+\tu32 value;\n+\tint ret;\n+\n+\t/ Wait until the queue is empty and its read controller is no longer\n+\t * pulling a frame out towards the MAC.\n+\t /\n+\tret = readl_poll_timeout(ioaddr + XGMAC_MTL_TXQ_DEBUG(queue), value,\n+\t\t\t\t !(value \u0026 XGMAC_TXQSTS) \u0026\u0026\n+\t\t\t\t FIELD_GET(XGMAC_TRCSTS, value) !=\n+\t\t\t\t XGMAC_TRCSTS_READ,\n+\t\t\t\t 100, 10000);\n+\tif (ret)\n+\t\tnetdev_warn(priv-\u003edev, \"MTL Tx queue %u drain timeout\\n\",\n+\t\t\t queue);\n+\n+\treturn ret;\n+}\n+\n+static int dwxgmac2_rx_mtl_drain(struct stmmac_priv priv,\n+\t\t\t\t void __iomem ioaddr, u32 queue)\n+{\n+\tu32 value;\n+\tint ret;\n+\n+\t/ Wait until no packet is left in the queue and the queue reports\n+\t * itself empty.\n+\t /\n+\tret = readl_poll_timeout(ioaddr + XGMAC_MTL_RXQ_DEBUG(queue), value,\n+\t\t\t\t !FIELD_GET(XGMAC_PRXQ, value) \u0026\u0026\n+\t\t\t\t !FIELD_GET(XGMAC_RXQSTS, value),\n+\t\t\t\t 100, 10000);\n+\tif (ret)\n+\t\tnetdev_warn(priv-\u003edev, \"MTL Rx queue %u drain timeout\\n\",\n+\t\t\t queue);\n+\n+\treturn ret;\n+}\n+\n+static int dwxgmac2_rx_dma_stopped(struct stmmac_priv priv,\n+\t\t\t\t void __iomem ioaddr, u32 chan)\n+{\n+\tu32 value;\n+\tint ret;\n+\n+\tret = readl_poll_timeout(ioaddr + XGMAC_DMA_CH_STATUS(chan), value,\n+\t\t\t\t value \u0026 XGMAC_RPS, 100, 10000);\n+\tif (ret)\n+\t\tnetdev_warn(priv-\u003edev, \"Rx DMA channel %u stop timeout\\n\",\n+\t\t\t chan);\n+\n+\treturn ret;\n+}\n+\n const struct stmmac_dma_ops dwxgmac210_dma_ops = {\n \t.reset = dwxgmac2_dma_reset,\n \t.init = dwxgmac2_dma_init,\n@@ -620,4 +686,8 @@ const struct stmmac_dma_ops dwxgmac210_dma_ops = {\n \t.set_bfsize = dwxgmac2_set_bfsize,\n \t.enable_sph = dwxgmac2_enable_sph,\n \t.enable_tbs = dwxgmac2_enable_tbs,\n+\t.tx_dma_stopped = dwxgmac2_tx_dma_stopped,\n+\t.tx_mtl_drain = dwxgmac2_tx_mtl_drain,\n+\t.rx_mtl_drain = dwxgmac2_rx_mtl_drain,\n+\t.rx_dma_stopped = dwxgmac2_rx_dma_stopped,\n };\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h\nindex 04dafec021b4f..86f4aa88961c7 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h\n+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h\n@@ -231,6 +231,15 @@ struct stmmac_dma_ops {\n \t\t\t bool en, u32 chan);\n \tint (enable_tbs)(struct stmmac_priv priv, void __iomem ioaddr,\n \t\t\t bool en, u32 chan);\n+\t/* Ordered datapath teardown /\n+\tint (tx_dma_stopped)(struct stmmac_priv priv, void __iomem ioaddr,\n+\t\t\t u32 chan);\n+\tint (tx_mtl_drain)(struct stmmac_priv priv, void __iomem ioaddr,\n+\t\t\t u32 queue);\n+\tint (rx_mtl_drain)(struct stmmac_priv priv, void __iomem ioaddr,\n+\t\t\t u32 queue);\n+\tint (rx_dma_stopped)(struct stmmac_priv priv, void __iomem ioaddr,\n+\t\t\t u32 chan);\n };\n \n #define stmmac_dma_init(__priv, __args...) \\\n@@ -293,6 +302,14 @@ struct stmmac_dma_ops {\n \tstmmac_do_void_callback(__priv, dma, enable_sph, __priv, __args)\n #define stmmac_enable_tbs(__priv, __args...) \\\n \tstmmac_do_callback(__priv, dma, enable_tbs, __priv, __args)\n+#define stmmac_tx_dma_stopped(__priv, __args...) \\\n+\tstmmac_do_callback(__priv, dma, tx_dma_stopped, __priv, __args)\n+#define stmmac_tx_mtl_drain(__priv, __args...) \\\n+\tstmmac_do_callback(__priv, dma, tx_mtl_drain, __priv, __args)\n+#define stmmac_rx_mtl_drain(__priv, __args...) \\\n+\tstmmac_do_callback(__priv, dma, rx_mtl_drain, __priv, __args)\n+#define stmmac_rx_dma_stopped(__priv, __args...) \\\n+\tstmmac_do_callback(__priv, dma, rx_dma_stopped, __priv, __args)\n \n struct mac_device_info;\n struct net_device;\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\nindex b2b7d0242dd3c..9c3a8f122b94f 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\n+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\n@@ -2560,6 +2560,52 @@ static void stmmac_stop_all_dma(struct stmmac_priv priv)\n \t\tstmmac_deinit_chan(priv, priv-\u003eioaddr, chan);\n }\n \n+/*\n+ stmmac_datapath_teardown - ordered datapath teardown as per IP specification\n+ * @priv: driver private structure\n+ * Description:\n+ * When teardown ops are available, follow the databook ordered teardown\n+ * sequence.\n+ * Follows the legacy stop + MAC disable for variants without the feature.\n+ /\n+static void stmmac_datapath_teardown(struct stmmac_priv priv)\n+{\n+\tu32 rx_channels_count = priv-\u003eplat-\u003erx_queues_to_use;\n+\tu32 tx_channels_count = priv-\u003eplat-\u003etx_queues_to_use;\n+\tu32 chan;\n+\n+\t/* Stop all TX DMA channels /\n+\tfor (chan = 0; chan \u003c tx_channels_count; chan++)\n+\t\tstmmac_stop_tx_dma(priv, chan);\n+\n+\t/ Wait for every TX DMA channel to report itself stopped /\n+\tif (priv-\u003ehw-\u003edma-\u003etx_dma_stopped)\n+\t\tfor (chan = 0; chan \u003c tx_channels_count; chan++)\n+\t\t\tstmmac_tx_dma_stopped(priv, priv-\u003eioaddr, chan);\n+\n+\t/ Wait for the MTL TX queues to finish pushing into the MAC /\n+\tif (priv-\u003ehw-\u003edma-\u003etx_mtl_drain)\n+\t\tfor (chan = 0; chan \u003c tx_channels_count; chan++)\n+\t\t\tstmmac_tx_mtl_drain(priv, priv-\u003eioaddr, chan);\n+\n+\t/ Disable the MAC TX and RX /\n+\tstmmac_mac_set(priv, priv-\u003eioaddr, false);\n+\n+\t/ Wait for the MTL RX queues to drain into the RX DMA /\n+\tif (priv-\u003ehw-\u003edma-\u003erx_mtl_drain)\n+\t\tfor (chan = 0; chan \u003c rx_channels_count; chan++)\n+\t\t\tstmmac_rx_mtl_drain(priv, priv-\u003eioaddr, chan);\n+\n+\t/ Stop all RX DMA channels /\n+\tfor (chan = 0; chan \u003c rx_channels_count; chan++)\n+\t\tstmmac_stop_rx_dma(priv, chan);\n+\n+\t/ Wait for every RX DMA channel to report itself stopped /\n+\tif (priv-\u003ehw-\u003edma-\u003erx_dma_stopped)\n+\t\tfor (chan = 0; chan \u003c rx_channels_count; chan++)\n+\t\t\tstmmac_rx_dma_stopped(priv, priv-\u003eioaddr, chan);\n+}\n+\n /\n stmmac_dma_operation_mode - HW DMA operation mode\n * @priv: driver private structure\n@@ -3685,9 +3731,6 @@ static int stmmac_hw_setup(struct net_device dev)\n \t\tpriv-\u003ehw-\u003erx_csum = 0;\n \t}\n \n-\t/ Enable the MAC Rx/Tx /\n-\tstmmac_mac_set(priv, priv-\u003eioaddr, true);\n-\n \t/ Set the HW DMA mode and the COE /\n \tstmmac_dma_operation_mode(priv);\n \n@@ -3743,6 +3786,9 @@ static int stmmac_hw_setup(struct net_device dev)\n \t/* Start the ball rolling... /\n \tstmmac_start_all_dma(priv);\n \n+\t/ Enable the MAC Rx/Tx /\n+\tstmmac_mac_set(priv, priv-\u003eioaddr, true);\n+\n \tphylink_rx_clk_stop_block(priv-\u003ephylink);\n \tstmmac_set_hw_vlan_mode(priv, priv-\u003ehw);\n \tphylink_rx_clk_stop_unblock(priv-\u003ephylink);\n@@ -4240,9 +4286,6 @@ static void __stmmac_release(struct net_device dev)\n \tstruct stmmac_priv priv = netdev_priv(dev);\n \tu8 chan;\n \n-\t/ Stop and disconnect the PHY /\n-\tphylink_stop(priv-\u003ephylink);\n-\n \tstmmac_disable_all_queues(priv);\n \n \tfor (chan = 0; chan \u003c priv-\u003eplat-\u003etx_queues_to_use; chan++)\n@@ -4253,8 +4296,11 @@ static void __stmmac_release(struct net_device dev)\n \t/* Free the IRQ lines /\n \tstmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);\n \n-\t/ Stop TX/RX DMA and clear the descriptors /\n-\tstmmac_stop_all_dma(priv);\n+\t/ Has to run before mac_link_down() disables the MAC. /\n+\tstmmac_datapath_teardown(priv);\n+\n+\t/ Stop and disconnect the PHY /\n+\tphylink_stop(priv-\u003ephylink);\n \n \t/ Release and free the Rx/Tx resources /\n \tfree_dma_desc_resources(priv, \u0026priv-\u003edma_conf);\n@@ -7104,15 +7150,12 @@ void stmmac_xdp_release(struct net_device dev)\n \t/* Free the IRQ lines /\n \tstmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);\n \n-\t/ Stop TX/RX DMA channels /\n-\tstmmac_stop_all_dma(priv);\n+\t/ Stop the MAC and the TX/RX DMA channels /\n+\tstmmac_datapath_teardown(priv);\n \n \t/ Release and free the Rx/Tx resources /\n \tfree_dma_desc_resources(priv, \u0026priv-\u003edma_conf);\n \n-\t/ Disable the MAC Rx/Tx /\n-\tstmmac_mac_set(priv, priv-\u003eioaddr, false);\n-\n \t/ set trans_start so we don't get spurious\n \t * watchdogs during reset\n \t /\n@@ -7184,12 +7227,12 @@ int stmmac_xdp_open(struct net_device dev)\n \t\thrtimer_setup(\u0026tx_q-\u003etxtimer, stmmac_tx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);\n \t}\n \n-\t/* Enable the MAC Rx/Tx /\n-\tstmmac_mac_set(priv, priv-\u003eioaddr, true);\n-\n \t/ Start Rx \u0026 Tx DMA Channels /\n \tstmmac_start_all_dma(priv);\n \n+\t/ Enable the MAC Rx/Tx /\n+\tstmmac_mac_set(priv, priv-\u003eioaddr, true);\n+\n \tret = stmmac_request_irq(dev);\n \tif (ret)\n \t\tgoto irq_error;\n@@ -8190,17 +8233,15 @@ int stmmac_suspend(struct device dev)\n \t\ttimer_delete_sync(\u0026priv-\u003eeee_ctrl_timer);\n \t}\n \n-\t/* Stop TX/RX DMA /\n-\tstmmac_stop_all_dma(priv);\n-\n-\tstmmac_legacy_serdes_power_down(priv);\n-\n \t/ Enable Power down mode by programming the PMT regs */\n \tif (priv-\u003ewolopts) {\n+\t\tstmmac_stop_all_dma(priv);\n+\t\tstmmac_legacy_serdes_power_down(priv);\n \t\tstmmac_pmt(priv, priv-\u003ehw, priv-\u003ewolopts);\n \t\tpriv-\u003eirq_wake = 1;\n \t} else {\n-\t\tstmmac_mac_set(priv, priv-\u003eioaddr, false);\n+\t\tstmmac_datapath_teardown(priv);\n+\t\tstmmac_legacy_serdes_power_down(priv);\n \t\tpinctrl_pm_select_sleep_state(priv-\u003edevice);\n \t}\n \n" }
2/1	2026/08/14 06:35	agent	patch-evaluator	3m Model: best-expensive Args: null Results: { "EnableConfigs": [ "STMMAC_ETH", "STMMAC_PCI" ], "FocusSymbols": [ "stmmac_dvr_remove", "stmmac_suspend", "stmmac_resume", "stmmac_xdp_open", "stmmac_xdp_release", "stmmac_reinit_queues", "stmmac_reinit_ringparam" ], "Reasoning": "The patch introduces a new ordered datapath teardown sequence for all stmmac devices, changing the order of DMA stop and MAC disable operations. It also swaps the order of MAC enable and DMA start in the setup paths. These are functional changes to the core driver logic reachable via PCI emulation.", "WorthFuzzing": true } Instruction: 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. Prompt: For your convenience, here is the diff of the changes: commit a08ff34cb2cd2d29c1e2615dd14480ccb2d870fb Author: syz-cluster <triage@syzkaller.com> Date: Fri Aug 14 06:35:32 2026 +0000 syz-cluster: applied patch under review diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h index f8ab347f7b5b9..50f9ccd4a9c46 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h @@ -291,6 +291,10 @@ #define XGMAC_TTC GENMASK(6, 4) #define XGMAC_TXQEN GENMASK(3, 2) #define XGMAC_TSF BIT(1) +#define XGMAC_MTL_TXQ_DEBUG(x) (0x00001108 + (0x80 * (x))) +#define XGMAC_TXQSTS BIT(4) +#define XGMAC_TRCSTS GENMASK(2, 1) +#define XGMAC_TRCSTS_READ 0x1 #define XGMAC_MTL_TCx_ETS_CONTROL(x) (0x00001110 + (0x80 * (x))) #define XGMAC_MTL_TCx_QUANTUM_WEIGHT(x) (0x00001118 + (0x80 * (x))) #define XGMAC_MTL_TCx_SENDSLOPE(x) (0x0000111c + (0x80 * (x))) @@ -306,6 +310,9 @@ #define XGMAC_EHFC BIT(7) #define XGMAC_RSF BIT(5) #define XGMAC_RTC GENMASK(1, 0) +#define XGMAC_MTL_RXQ_DEBUG(x) (0x00001148 + (0x80 * (x))) +#define XGMAC_PRXQ GENMASK(29, 16) +#define XGMAC_RXQSTS GENMASK(5, 4) #define XGMAC_MTL_RXQ_FLOW_CONTROL(x) (0x00001150 + (0x80 * (x))) #define XGMAC_RFD GENMASK(31, 17) #define XGMAC_RFA GENMASK(15, 1) @@ -391,6 +398,7 @@ #define XGMAC_NIS BIT(15) #define XGMAC_AIS BIT(14) #define XGMAC_FBE BIT(12) +#define XGMAC_RPS BIT(8) #define XGMAC_RBU BIT(7) #define XGMAC_RI BIT(6) #define XGMAC_TBU BIT(2) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c index ff83858ebc1f3..ba4f535fb9eb4 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c @@ -4,6 +4,7 @@ * stmmac XGMAC support. / +#include <linux/bitfield.h> #include <linux/iopoll.h> #include "stmmac.h" #include "dwxgmac2.h" @@ -261,13 +262,12 @@ static void dwxgmac2_dma_start_tx(struct stmmac_priv priv, { u32 value; + /* TPS is latched once set, so clear it on every Tx DMA start. / + writel(XGMAC_TPS, ioaddr + XGMAC_DMA_CH_STATUS(chan)); + value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); value \|= XGMAC_TXST; writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); - - value = readl(ioaddr + XGMAC_TX_CONFIG); - value \|= XGMAC_CONFIG_TE; - writel(value, ioaddr + XGMAC_TX_CONFIG); } static void dwxgmac2_dma_stop_tx(struct stmmac_priv priv, void __iomem ioaddr, @@ -278,10 +278,6 @@ static void dwxgmac2_dma_stop_tx(struct stmmac_priv priv, void __iomem ioaddr, value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); value &= ~XGMAC_TXST; writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); - - value = readl(ioaddr + XGMAC_TX_CONFIG); - value &= ~XGMAC_CONFIG_TE; - writel(value, ioaddr + XGMAC_TX_CONFIG); } static void dwxgmac2_dma_start_rx(struct stmmac_priv priv, @@ -289,13 +285,12 @@ static void dwxgmac2_dma_start_rx(struct stmmac_priv priv, { u32 value; + / RPS is latched once set, so clear it on every Rx DMA start. / + writel(XGMAC_RPS, ioaddr + XGMAC_DMA_CH_STATUS(chan)); + value = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan)); value \|= XGMAC_RXST; writel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan)); - - value = readl(ioaddr + XGMAC_RX_CONFIG); - value \|= XGMAC_CONFIG_RE; - writel(value, ioaddr + XGMAC_RX_CONFIG); } static void dwxgmac2_dma_stop_rx(struct stmmac_priv priv, void __iomem ioaddr, @@ -592,6 +587,77 @@ static int dwxgmac2_enable_tbs(struct stmmac_priv priv, void __iomem ioaddr, return 0; } +static int dwxgmac2_tx_dma_stopped(struct stmmac_priv priv, + void __iomem ioaddr, u32 chan) +{ + u32 value; + int ret; + + ret = readl_poll_timeout(ioaddr + XGMAC_DMA_CH_STATUS(chan), value, + value & XGMAC_TPS, 100, 10000); + if (ret) + netdev_warn(priv->dev, "Tx DMA channel %u stop timeout\n", + chan); + + return ret; +} + +static int dwxgmac2_tx_mtl_drain(struct stmmac_priv priv, + void __iomem ioaddr, u32 queue) +{ + u32 value; + int ret; + + / Wait until the queue is empty and its read controller is no longer + * pulling a frame out towards the MAC. + / + ret = readl_poll_timeout(ioaddr + XGMAC_MTL_TXQ_DEBUG(queue), value, + !(value & XGMAC_TXQSTS) && + FIELD_GET(XGMAC_TRCSTS, value) != + XGMAC_TRCSTS_READ, + 100, 10000); + if (ret) + netdev_warn(priv->dev, "MTL Tx queue %u drain timeout\n", + queue); + + return ret; +} + +static int dwxgmac2_rx_mtl_drain(struct stmmac_priv priv, + void __iomem ioaddr, u32 queue) +{ + u32 value; + int ret; + + / Wait until no packet is left in the queue and the queue reports + * itself empty. + / + ret = readl_poll_timeout(ioaddr + XGMAC_MTL_RXQ_DEBUG(queue), value, + !FIELD_GET(XGMAC_PRXQ, value) && + !FIELD_GET(XGMAC_RXQSTS, value), + 100, 10000); + if (ret) + netdev_warn(priv->dev, "MTL Rx queue %u drain timeout\n", + queue); + + return ret; +} + +static int dwxgmac2_rx_dma_stopped(struct stmmac_priv priv, + void __iomem ioaddr, u32 chan) +{ + u32 value; + int ret; + + ret = readl_poll_timeout(ioaddr + XGMAC_DMA_CH_STATUS(chan), value, + value & XGMAC_RPS, 100, 10000); + if (ret) + netdev_warn(priv->dev, "Rx DMA channel %u stop timeout\n", + chan); + + return ret; +} + const struct stmmac_dma_ops dwxgmac210_dma_ops = { .reset = dwxgmac2_dma_reset, .init = dwxgmac2_dma_init, @@ -620,4 +686,8 @@ const struct stmmac_dma_ops dwxgmac210_dma_ops = { .set_bfsize = dwxgmac2_set_bfsize, .enable_sph = dwxgmac2_enable_sph, .enable_tbs = dwxgmac2_enable_tbs, + .tx_dma_stopped = dwxgmac2_tx_dma_stopped, + .tx_mtl_drain = dwxgmac2_tx_mtl_drain, + .rx_mtl_drain = dwxgmac2_rx_mtl_drain, + .rx_dma_stopped = dwxgmac2_rx_dma_stopped, }; diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h index 04dafec021b4f..86f4aa88961c7 100644 --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h @@ -231,6 +231,15 @@ struct stmmac_dma_ops { bool en, u32 chan); int (enable_tbs)(struct stmmac_priv priv, void __iomem ioaddr, bool en, u32 chan); + /* Ordered datapath teardown / + int (tx_dma_stopped)(struct stmmac_priv priv, void __iomem ioaddr, + u32 chan); + int (tx_mtl_drain)(struct stmmac_priv priv, void __iomem ioaddr, + u32 queue); + int (rx_mtl_drain)(struct stmmac_priv priv, void __iomem ioaddr, + u32 queue); + int (rx_dma_stopped)(struct stmmac_priv priv, void __iomem ioaddr, + u32 chan); }; #define stmmac_dma_init(__priv, __args...) \ @@ -293,6 +302,14 @@ struct stmmac_dma_ops { stmmac_do_void_callback(__priv, dma, enable_sph, __priv, __args) #define stmmac_enable_tbs(__priv, __args...) \ stmmac_do_callback(__priv, dma, enable_tbs, __priv, __args) +#define stmmac_tx_dma_stopped(__priv, __args...) \ + stmmac_do_callback(__priv, dma, tx_dma_stopped, __priv, __args) +#define stmmac_tx_mtl_drain(__priv, __args...) \ + stmmac_do_callback(__priv, dma, tx_mtl_drain, __priv, __args) +#define stmmac_rx_mtl_drain(__priv, __args...) \ + stmmac_do_callback(__priv, dma, rx_mtl_drain, __priv, __args) +#define stmmac_rx_dma_stopped(__priv, __args...) \ + stmmac_do_callback(__priv, dma, rx_dma_stopped, __priv, __args) struct mac_device_info; struct net_device; diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index b2b7d0242dd3c..9c3a8f122b94f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2560,6 +2560,52 @@ static void stmmac_stop_all_dma(struct stmmac_priv priv) stmmac_deinit_chan(priv, priv->ioaddr, chan); } +/** + * stmmac_datapath_teardown - ordered datapath teardown as per IP specification + * @priv: driver private structure + * Description: + * When teardown ops are available, follow the databook ordered teardown + * sequence. + * Follows the legacy stop + MAC disable for variants without the feature. + / +static void stmmac_datapath_teardown(struct stmmac_priv priv) +{ + u32 rx_channels_count = priv->plat->rx_queues_to_use; + u32 tx_channels_count = priv->plat->tx_queues_to_use; + u32 chan; + + /* Stop all TX DMA channels / + for (chan = 0; chan < tx_channels_count; chan++) + stmmac_stop_tx_dma(priv, chan); + + / Wait for every TX DMA channel to report itself stopped / + if (priv->hw->dma->tx_dma_stopped) + for (chan = 0; chan < tx_channels_count; chan++) + stmmac_tx_dma_stopped(priv, priv->ioaddr, chan); + + / Wait for the MTL TX queues to finish pushing into the MAC / + if (priv->hw->dma->tx_mtl_drain) + for (chan = 0; chan < tx_channels_count; chan++) + stmmac_tx_mtl_drain(priv, priv->ioaddr, chan); + + / Disable the MAC TX and RX / + stmmac_mac_set(priv, priv->ioaddr, false); + + / Wait for the MTL RX queues to drain into the RX DMA / + if (priv->hw->dma->rx_mtl_drain) + for (chan = 0; chan < rx_channels_count; chan++) + stmmac_rx_mtl_drain(priv, priv->ioaddr, chan); + + / Stop all RX DMA channels / + for (chan = 0; chan < rx_channels_count; chan++) + stmmac_stop_rx_dma(priv, chan); + + / Wait for every RX DMA channel to report itself stopped / + if (priv->hw->dma->rx_dma_stopped) + for (chan = 0; chan < rx_channels_count; chan++) + stmmac_rx_dma_stopped(priv, priv->ioaddr, chan); +} + /* * stmmac_dma_operation_mode - HW DMA operation mode * @priv: driver private structure @@ -3685,9 +3731,6 @@ static int stmmac_hw_setup(struct net_device dev) priv->hw->rx_csum = 0; } - / Enable the MAC Rx/Tx / - stmmac_mac_set(priv, priv->ioaddr, true); - / Set the HW DMA mode and the COE / stmmac_dma_operation_mode(priv); @@ -3743,6 +3786,9 @@ static int stmmac_hw_setup(struct net_device dev) /* Start the ball rolling... / stmmac_start_all_dma(priv); + / Enable the MAC Rx/Tx / + stmmac_mac_set(priv, priv->ioaddr, true); + phylink_rx_clk_stop_block(priv->phylink); stmmac_set_hw_vlan_mode(priv, priv->hw); phylink_rx_clk_stop_unblock(priv->phylink); @@ -4240,9 +4286,6 @@ static void __stmmac_release(struct net_device dev) struct stmmac_priv priv = netdev_priv(dev); u8 chan; - / Stop and disconnect the PHY / - phylink_stop(priv->phylink); - stmmac_disable_all_queues(priv); for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++) @@ -4253,8 +4296,11 @@ static void __stmmac_release(struct net_device dev) /* Free the IRQ lines / stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0); - / Stop TX/RX DMA and clear the descriptors / - stmmac_stop_all_dma(priv); + / Has to run before mac_link_down() disables the MAC. / + stmmac_datapath_teardown(priv); + + / Stop and disconnect the PHY / + phylink_stop(priv->phylink); / Release and free the Rx/Tx resources / free_dma_desc_resources(priv, &priv->dma_conf); @@ -7104,15 +7150,12 @@ void stmmac_xdp_release(struct net_device dev) /* Free the IRQ lines / stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0); - / Stop TX/RX DMA channels / - stmmac_stop_all_dma(priv); + / Stop the MAC and the TX/RX DMA channels / + stmmac_datapath_teardown(priv); / Release and free the Rx/Tx resources / free_dma_desc_resources(priv, &priv->dma_conf); - / Disable the MAC Rx/Tx / - stmmac_mac_set(priv, priv->ioaddr, false); - / set trans_start so we don't get spurious * watchdogs during reset / @@ -7184,12 +7227,12 @@ int stmmac_xdp_open(struct net_device dev) hrtimer_setup(&tx_q->txtimer, stmmac_tx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); } - /* Enable the MAC Rx/Tx / - stmmac_mac_set(priv, priv->ioaddr, true); - / Start Rx & Tx DMA Channels / stmmac_start_all_dma(priv); + / Enable the MAC Rx/Tx / + stmmac_mac_set(priv, priv->ioaddr, true); + ret = stmmac_request_irq(dev); if (ret) goto irq_error; @@ -8190,17 +8233,15 @@ int stmmac_suspend(struct device dev) timer_delete_sync(&priv->eee_ctrl_timer); } - /* Stop TX/RX DMA / - stmmac_stop_all_dma(priv); - - stmmac_legacy_serdes_power_down(priv); - / Enable Power down mode by programming the PMT regs */ if (priv->wolopts) { + stmmac_stop_all_dma(priv); + stmmac_legacy_serdes_power_down(priv); stmmac_pmt(priv, priv->hw, priv->wolopts); priv->irq_wake = 1; } else { - stmmac_mac_set(priv, priv->ioaddr, false); + stmmac_datapath_teardown(priv); + stmmac_legacy_serdes_power_down(priv); pinctrl_pm_select_sleep_state(priv->device); }
3/2	2026/08/14 06:35	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7384 output: 20 thoughts: 373 Thoughts: Analyzing the Impact of the STMMAC Driver Patch Okay, so I've got this patch that adds ordered datapath teardown logic for dwxgmac2 within the stmmac driver. It's touching `stmmac_main.c` to swap out the old shutdown sequence for `stmmac_datapath_teardown()`, and it's also reordering some functions in `stmmac_hw_setup` and `stmmac_xdp_open`. My primary concern now is to determine the reach of this change. Specifically, I need to know how likely it is that this driver is hit in any virtualized environment. The stmmac driver, from what I know, is used for Synopsys DesignWare MACs. A quick check tells me that while QEMU doesn't directly emulate stmmac by default, that doesn’t mean it's never used. It’s definitely plausible it's part of the emulated hardware on some ARM boards using QEMU. Time to confirm if any QEMU boards actually do use stmmac. Considering the wide range of SoCs that use stmmac, I need to consider a range of possibilities, even those accessed through a PCI device or platform device in QEMU. I should check if there's any mention of `stmmac` within the QEMU configuration or if `CONFIG_STMMAC_ETH` is enabled in syzkaller. Aha, and then I recalled that `stmmac` actually has a PCI driver, `stmmac_pci.c`. This could open up a whole new attack surface if we could trigger it through some generic PCI device setup. I should find out if `stmmac_pci` is specifically tied to some Intel or AMD SoCs or if it’s more generic and applicable to a wider range of hardware emulated by QEMU.
4/2	2026/08/14 06:35	tool	grepper	0m Args: { "Expression": "stmmac_pci" } Results: { "Output": "Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst=107=syntax (e.g. for PCI module)::\nDocumentation/networking/device_drivers/ethernet/stmicro/stmmac.rst-108-\nDocumentation/networking/device_drivers/ethernet/stmicro/stmmac.rst:109: modprobe stmmac_pci [\u003coption\u003e=\u003cVAL1\u003e,\u003cVAL2\u003e,...]\nDocumentation/networking/device_drivers/ethernet/stmicro/stmmac.rst-110-\n--\ndrivers/net/ethernet/stmicro/stmmac/Makefile=53=obj-$(CONFIG_DWMAC_MOTORCOMM)\t+= dwmac-motorcomm.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:54:stmmac-pci-objs:= stmmac_pci.o\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=25=struct intel_priv_data {\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-39- /\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:40:struct stmmac_pci_func_data {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-41-\tunsigned int func;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-44-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:45:struct stmmac_pci_dmi_data {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:46:\tconst struct stmmac_pci_func_data func;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-47-\tsize_t nfuncs;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-49-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:50:struct stmmac_pci_info {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-51-\tint (setup)(struct pci_dev pdev, struct plat_stmmacenet_data plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=91=static const int adln_tsn_lane_regs[] = {6};\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-92-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:93:static int stmmac_pci_find_phy_addr(struct pci_dev pdev,\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-94-\t\t\t\t const struct dmi_system_id dmi_list)\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-95-{\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:96:\tconst struct stmmac_pci_func_data func_data;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:97:\tconst struct stmmac_pci_dmi_data dmi_data;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-98-\tconst struct dmi_system_id dmi_id;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=786=static int ehl_sgmii_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-805-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:806:static struct stmmac_pci_info ehl_sgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-807-\t.setup = ehl_sgmii_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=810=static int ehl_rgmii_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-820-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:821:static struct stmmac_pci_info ehl_rgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-822-\t.setup = ehl_rgmii_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=841=static int ehl_pse0_rgmii1g_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-847-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:848:static struct stmmac_pci_info ehl_pse0_rgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-849-\t.setup = ehl_pse0_rgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=852=static int ehl_pse0_sgmii1g_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-869-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:870:static struct stmmac_pci_info ehl_pse0_sgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-871-\t.setup = ehl_pse0_sgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=890=static int ehl_pse1_rgmii1g_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-896-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:897:static struct stmmac_pci_info ehl_pse1_rgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-898-\t.setup = ehl_pse1_rgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=901=static int ehl_pse1_sgmii1g_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-918-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:919:static struct stmmac_pci_info ehl_pse1_sgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-920-\t.setup = ehl_pse1_sgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=944=static int tgl_sgmii_phy0_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-952-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:953:static struct stmmac_pci_info tgl_sgmii1g_phy0_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-954-\t.setup = tgl_sgmii_phy0_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=957=static int tgl_sgmii_phy1_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-965-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:966:static struct stmmac_pci_info tgl_sgmii1g_phy1_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-967-\t.setup = tgl_sgmii_phy1_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=970=static int adls_sgmii_phy0_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-979-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:980:static struct stmmac_pci_info adls_sgmii1g_phy0_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-981-\t.setup = adls_sgmii_phy0_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=984=static int adls_sgmii_phy1_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-993-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:994:static struct stmmac_pci_info adls_sgmii1g_phy1_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-995-\t.setup = adls_sgmii_phy1_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1023=static int adln_sgmii_phy0_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1041-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1042:static struct stmmac_pci_info adln_sgmii1g_phy0_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1043-\t.setup = adln_sgmii_phy0_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1045-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1046:static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1047-\t{\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1052-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1053:static const struct stmmac_pci_dmi_data galileo_stmmac_dmi_data = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1054-\t.func = galileo_stmmac_func_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1057-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1058:static const struct stmmac_pci_func_data iot2040_stmmac_func_data[] = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1059-\t{\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1068-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1069:static const struct stmmac_pci_dmi_data iot2040_stmmac_dmi_data = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1070-\t.func = iot2040_stmmac_func_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1109=static int quark_default_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1119-\t /\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1120:\tret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1121-\tif (ret \u003c 0) {\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1144-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1145:static const struct stmmac_pci_info quark_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1146-\t.setup = quark_default_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1263=static int intel_eth_pci_probe(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1265-{\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1266:\tstruct stmmac_pci_info info = (struct stmmac_pci_info )id-\u003edriver_data;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1267-\tstruct intel_priv_data intel_priv;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=76=struct loongson_data {\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-81-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:82:struct stmmac_pci_info {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-83-\tint (setup)(struct pci_dev pdev, struct plat_stmmacenet_data plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=132=static int loongson_gmac_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-141-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:142:static struct stmmac_pci_info loongson_gmac_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-143-\t.setup = loongson_gmac_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=165=static int loongson_gnet_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-176-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:177:static struct stmmac_pci_info loongson_gnet_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-178-\t.setup = loongson_gnet_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=498=static int loongson_dwmac_probe(struct pci_dev pdev, const struct pci_device_id id)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-501-\tstruct stmmac_resources res = {};\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:502:\tstruct stmmac_pci_info info;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-503-\tstruct loongson_data ld;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-537-\tplat-\u003efix_soc_reset = loongson_dwmac_fix_reset;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:538:\tplat-\u003esuspend = stmmac_pci_plat_suspend;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:539:\tplat-\u003eresume = stmmac_pci_plat_resume;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-540-\tld-\u003edev = \u0026pdev-\u003edev;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-542-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:543:\tinfo = (struct stmmac_pci_info )id-\u003edriver_data;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-544-\tret = info-\u003esetup(pdev, plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c=188=static int motorcomm_resume(struct device dev, void bsp_priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-192-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c:193:\tret = stmmac_pci_plat_resume(dev, bsp_priv);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-194-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c=208=motorcomm_default_plat_data(struct pci_dev pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-248-\tplat-\u003ecore_type\t\t= DWMAC_CORE_GMAC4;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c:249:\tplat-\u003esuspend\t\t= stmmac_pci_plat_suspend;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-250-\tplat-\u003eresume\t\t= motorcomm_resume;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-11-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c:12:int stmmac_pci_plat_suspend(struct device dev, void bsp_priv)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-13-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-25-}\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c:26:EXPORT_SYMBOL_GPL(stmmac_pci_plat_suspend);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-27-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c:28:int stmmac_pci_plat_resume(struct device dev, void bsp_priv)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-29-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-43-}\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c:44:EXPORT_SYMBOL_GPL(stmmac_pci_plat_resume);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.c-45-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.h-8-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.h:9:int stmmac_pci_plat_suspend(struct device dev, void bsp_priv);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.h:10:int stmmac_pci_plat_resume(struct device dev, void bsp_priv);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_libpci.h-11-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-18-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:19:struct stmmac_pci_info {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-20-\tint (setup)(struct pci_dev pdev, struct plat_stmmacenet_data plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=33=static int stmmac_default_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-49-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:50:static const struct stmmac_pci_info stmmac_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-51-\t.setup = stmmac_default_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=54=static int snps_gmac5_default_data(struct pci_dev pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-101-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:102:static const struct stmmac_pci_info snps_gmac5_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-103-\t.setup = snps_gmac5_default_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-106-/\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:107: stmmac_pci_probe\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-108- \n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-117- /\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:118:static int stmmac_pci_probe(struct pci_dev pdev,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-119-\t\t\t const struct pci_device_id id)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-120-{\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:121:\tstruct stmmac_pci_info info = (struct stmmac_pci_info )id-\u003edriver_data;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-122-\tstruct plat_stmmacenet_data plat;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-179-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:180:\tplat-\u003esuspend = stmmac_pci_plat_suspend;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:181:\tplat-\u003eresume = stmmac_pci_plat_resume;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-182-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-186-/\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:187: stmmac_pci_remove\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-188- \n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-191- /\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:192:static void stmmac_pci_remove(struct pci_dev *pdev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-193-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=203=static const struct pci_device_id stmmac_id_table[] = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:204:\t{ PCI_DEVICE_DATA(STMMAC, STMMAC, \u0026stmmac_pci_info) },\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:205:\t{ PCI_DEVICE_DATA(STMICRO, MAC, \u0026stmmac_pci_info) },\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-206-\t{ PCI_DEVICE_DATA(SYNOPSYS, GMAC5_ID, \u0026snps_gmac5_pci_info) },\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=210=MODULE_DEVICE_TABLE(pci, stmmac_id_table);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-211-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:212:static struct pci_driver stmmac_pci_driver = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-213-\t.name = STMMAC_RESOURCE_NAME,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-214-\t.id_table = stmmac_id_table,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:215:\t.probe = stmmac_pci_probe,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:216:\t.remove = stmmac_pci_remove,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-217-\t.driver = {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-221-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:222:module_pci_driver(stmmac_pci_driver);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-223-\n" }
5/2	2026/08/14 06:35	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 15543 output: 25 thoughts: 191 Thoughts: My Initial Assessment of the Situation Okay, so I'm looking at `stmmac_pci`. My immediate thought is that this is a PCI driver that syzkaller should be able to probe, no problem. I need to make sure I'm right about that. Hmmm, hold on... `stmmac` seems to be fairly widely used, popping up in `dwmac-intel.c`, `dwmac-loongson.c`, and `dwmac-motorcomm.c` as well. That broadens the scope of things. And yes, confirming my initial hunch, `stmmac_pci` specifically binds itself to `PCI_DEVICE_DATA(STMMAC, STMMAC, &stmmac_pci_info)`. This means syzkaller can definitely fuzz it effectively by emulating a PCI device with the right vendor and device ID. That’s a good starting point. Now, the more interesting question: is `dwxgmac2` within reach? I need to analyze this further. This recent patch seems to be focused on `dwxgmac2_dma.c`, which implements `dwxgmac210_dma_ops`. Time to trace that, see where `dwxgmac210_dma_ops` is actually used.
6/2	2026/08/14 06:35	tool	grepper	0m Args: { "Expression": "dwxgmac210_dma_ops" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h=474=extern const struct stmmac_ops dwxlgmac2_ops;\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h:475:extern const struct stmmac_dma_ops dwxgmac210_dma_ops;\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h-476-extern const struct stmmac_desc_ops dwxgmac210_desc_ops;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c=646=static int dwxgmac2_rx_dma_stopped(struct stmmac_priv *priv,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c-660-\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c:661:const struct stmmac_dma_ops dwxgmac210_dma_ops = {\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c-662-\t.reset = dwxgmac2_dma_reset,\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=111=static const struct stmmac_hwif_entry {\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-257-\t\t.desc = \u0026dwxgmac210_desc_ops,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:258:\t\t.dma = \u0026dwxgmac210_dma_ops,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-259-\t\t.mac = \u0026dwxgmac210_ops,\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-279-\t\t.desc = \u0026dwxgmac210_desc_ops,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:280:\t\t.dma = \u0026dwxgmac210_dma_ops,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-281-\t\t.mac = \u0026dwxlgmac2_ops,\n" }
7/2	2026/08/14 06:35	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 16651 output: 22 thoughts: 16 Thoughts: Okay, let's dive into this. Here's my take on those initial thoughts: Analyzing `hwif.c`'s Interaction with Data Entries Right, so I'm looking at `hwif.c`. My immediate thought is, "Okay, what does this particular code module actually do with these data entries?" I need to understand the processing flow, the manipulations, and the eventual destination or purpose of these entries within the context of the hardware interface. I need to figure out the roles. Is it a reader? A writer? A translator? A filter? Probably a combination. But first, the mechanics of its interaction are paramount. I need to trace the data's journey and see how the functions within `hwif.c` handle them. That's the key to understanding its overall impact.
8/2	2026/08/14 06:35	tool	grepper	0m Args: { "Expression": "dwxgmac210_ops" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h-472-\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h:473:extern const struct stmmac_ops dwxgmac210_ops;\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h-474-extern const struct stmmac_ops dwxlgmac2_ops;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c=1413=static void dwxgmac2_set_arp_offload(struct mac_device_info *hw, bool en,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c-1428-\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1429:const struct stmmac_ops dwxgmac210_ops = {\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c-1430-\t.core_init = dwxgmac2_core_init,\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=111=static const struct stmmac_hwif_entry {\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-258-\t\t.dma = \u0026dwxgmac210_dma_ops,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:259:\t\t.mac = \u0026dwxgmac210_ops,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-260-\t\t.vlan = \u0026dwxgmac210_vlan_ops,\n" }
9/2	2026/08/14 06:35	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 17326 output: 22 thoughts: 21 Thoughts: Here's my summary, as if I were thinking these thoughts: Analyzing the STMMAC Hardware Interface Entry Point Okay, time to dig in. I need to understand how the hardware interface is initialized and accessed for this STMMAC driver. The most logical starting point is probably `stmmac_hwif_entry` within `hwif.c`. I expect this function to be the central point of interaction with the hardware abstraction layer (HAL) for this specific Ethernet MAC. I anticipate finding initialization routines, register mapping setups, and likely interrupt configuration related to the hardware within this entry function or a call chain originating from it. This will provide valuable insight into how the driver interacts with the underlying hardware components and how it's configured. Let's get to it.
10/2	2026/08/14 06:36	tool	grepper	0m Args: { "Expression": "stmmac_hwif_entry" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/hwif.c=100=int stmmac_reset(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-110-\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:111:static const struct stmmac_hwif_entry {\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-112-\tenum dwmac_core_type core_type;\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-292-\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:293:static const struct stmmac_hwif_entry \ndrivers/net/ethernet/stmicro/stmmac/hwif.c-294-stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-295-{\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:296:\tconst struct stmmac_hwif_entry entry;\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-297-\tint i;\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=317=int stmmac_hwif_init(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-319-\tenum dwmac_core_type core_type = priv-\u003eplat-\u003ecore_type;\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:320:\tconst struct stmmac_hwif_entry *entry;\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-321-\tstruct stmmac_version version;\n" }
11/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 18051 output: 46 thoughts: 26 Thoughts: Here's my attempt at summarizing that thought process, tailored for an expert audience: Mapping `core_type` to `dwxgmac210_dma_ops` Okay, so I'm looking at how the `core_type` enumeration relates to the `dwxgmac210_dma_ops` structures. It's a classic situation where a hardware abstraction needs to be linked to a specific implementation. I'm probably dealing with a system that has potentially multiple DMA controllers, or at least different configurations, and the `core_type` is the key to selecting the right set of DMA operations. My primary focus right now is to understand the lookup mechanism. Is it a simple switch statement? Maybe a lookup table? Are there any indirect layers of abstraction I need to understand? Given that this is likely tied to the design of the driver and platform, I need to know: Are there any compatibility layers, or special cases to be aware of? Are there architectural considerations here? Does this relationship affect the power management, clock gating, or interrupt handling behavior? Ultimately, the goal is a complete picture. Once I've mapped the potential values of `core_type` to the correct `dwxgmac210_dma_ops` structure, I'll know where to look next to understand the details of the DMA operations. I have a lot of debugging to do!
12/2	2026/08/14 06:36	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/hwif.c", "FirstLine": 250, "LineCount": 50 } Results: { "Contents": " 250:\t\t\t.dev_id = DWXGMAC_ID,\n 251:\t\t\t.regs = {\n 252:\t\t\t\t.ptp_off = PTP_XGMAC_OFFSET,\n 253:\t\t\t\t.mmc_off = MMC_XGMAC_OFFSET,\n 254:\t\t\t\t.est_off = EST_XGMAC_OFFSET,\n 255:\t\t\t\t.fpe_reg = \u0026dwxgmac3_fpe_reg,\n 256:\t\t\t},\n 257:\t\t\t.desc = \u0026dwxgmac210_desc_ops,\n 258:\t\t\t.dma = \u0026dwxgmac210_dma_ops,\n 259:\t\t\t.mac = \u0026dwxgmac210_ops,\n 260:\t\t\t.vlan = \u0026dwxgmac210_vlan_ops,\n 261:\t\t\t.hwtimestamp = \u0026stmmac_ptp,\n 262:\t\t\t.ptp = \u0026stmmac_ptp_clock_ops,\n 263:\t\t\t.mode = NULL,\n 264:\t\t\t.tc = \u0026dwmac510_tc_ops,\n 265:\t\t\t.mmc = \u0026dwxgmac_mmc_ops,\n 266:\t\t\t.est = \u0026dwmac510_est_ops,\n 267:\t\t\t.setup = dwxgmac2_setup,\n 268:\t\t\t.quirks = NULL,\n 269:\t\t}, {\n 270:\t\t\t.core_type = DWMAC_CORE_XGMAC,\n 271:\t\t\t.min_id = DWXLGMAC_CORE_2_00,\n 272:\t\t\t.dev_id = DWXLGMAC_ID,\n 273:\t\t\t.regs = {\n 274:\t\t\t\t.ptp_off = PTP_XGMAC_OFFSET,\n 275:\t\t\t\t.mmc_off = MMC_XGMAC_OFFSET,\n 276:\t\t\t\t.est_off = EST_XGMAC_OFFSET,\n 277:\t\t\t\t.fpe_reg = \u0026dwxgmac3_fpe_reg,\n 278:\t\t\t},\n 279:\t\t\t.desc = \u0026dwxgmac210_desc_ops,\n 280:\t\t\t.dma = \u0026dwxgmac210_dma_ops,\n 281:\t\t\t.mac = \u0026dwxlgmac2_ops,\n 282:\t\t\t.vlan = \u0026dwxlgmac2_vlan_ops,\n 283:\t\t\t.hwtimestamp = \u0026stmmac_ptp,\n 284:\t\t\t.ptp = \u0026stmmac_ptp_clock_ops,\n 285:\t\t\t.mode = NULL,\n 286:\t\t\t.tc = \u0026dwmac510_tc_ops,\n 287:\t\t\t.mmc = \u0026dwxgmac_mmc_ops,\n 288:\t\t\t.est = \u0026dwmac510_est_ops,\n 289:\t\t\t.setup = dwxlgmac2_setup,\n 290:\t\t},\n 291:\t};\n 292:\t\n 293:\tstatic const struct stmmac_hwif_entry \n 294:\tstmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)\n 295:\t{\n 296:\t\tconst struct stmmac_hwif_entry entry;\n 297:\t\tint i;\n 298:\t\n 299:\t\tfor (i = ARRAY_SIZE(stmmac_hw) - 1; i \u003e= 0; i--) {\n" }
13/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 19356 output: 23 thoughts: 63 Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective: Investigating XGMAC Core Driver Association Alright, so the `DWMAC_CORE_XGMAC` core is associated with the `dwxgmac210_dma_ops` operations. My mind immediately jumps to the PCI drivers, specifically `stmmac_pci`, to understand how this connection is established at the hardware level. I need to quickly determine whether any of the PCI drivers, or perhaps other drivers I'm familiar with, specifically set that `core_type` to `DWMAC_CORE_XGMAC`. This is a vital step in understanding the device's setup and its configuration within the system. I'm focusing on the configuration of this core, and I need to determine how it's being handled by the system.
14/2	2026/08/14 06:36	tool	grepper	0m Args: { "Expression": "DWMAC_CORE_XGMAC" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/common.h=49=static inline bool dwmac_is_xmac(enum dwmac_core_type core_type)\ndrivers/net/ethernet/stmicro/stmmac/common.h-50-{\ndrivers/net/ethernet/stmicro/stmmac/common.h:51:\treturn core_type == DWMAC_CORE_GMAC4 \|\| core_type == DWMAC_CORE_XGMAC;\ndrivers/net/ethernet/stmicro/stmmac/common.h-52-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c=569=static void socfpga_agilex5_setup_plat_dat(struct socfpga_dwmac dwmac)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c-572-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:573:\tplat_dat-\u003ecore_type = DWMAC_CORE_XGMAC;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c-574-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c=214=static int tegra_mgbe_probe(struct platform_device pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c-325-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c:326:\tplat-\u003ecore_type = DWMAC_CORE_XGMAC;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c-327-\tplat-\u003eflags \|= STMMAC_FLAG_TSO_EN;\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=21=static void stmmac_get_version(struct stmmac_priv priv,\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-49-\tver-\u003esnpsver = FIELD_GET(DWMAC_SNPSVER, version);\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:50:\tif (core_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-51-\t\tver-\u003edev_id = FIELD_GET(DWMAC_USERVER, version);\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=111=static const struct stmmac_hwif_entry {\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-247-\t}, {\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:248:\t\t.core_type = DWMAC_CORE_XGMAC,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-249-\t\t.min_id = DWXGMAC_CORE_2_10,\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-269-\t}, {\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:270:\t\t.core_type = DWMAC_CORE_XGMAC,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-271-\t\t.min_id = DWXLGMAC_CORE_2_00,\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=294=stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-306-\t\t\tcontinue;\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:307:\t\tif (core_type == DWMAC_CORE_XGMAC \u0026\u0026\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-308-\t\t dev_id != entry-\u003edev_id)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c=28=static int est_configure(struct stmmac_priv priv, struct stmmac_est cfg,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c-55-\tctrl = readl(est_addr + EST_CONTROL);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c:56:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c-57-\t\tctrl \u0026= ~EST_XGMAC_PTOV;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c=83=static void est_irq_status(struct stmmac_priv priv, struct net_device dev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c-150-\tif (status \u0026 EST_BTRE) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c:151:\t\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_est.c-152-\t\t\tbtrl = FIELD_GET(EST_XGMAC_BTRL, status);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c=301=static void stmmac_ethtool_getdrvinfo(struct net_device dev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-308-\t\tstrscpy(info-\u003edriver, GMAC_ETHTOOL_NAME, sizeof(info-\u003edriver));\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c:309:\telse if (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-310-\t\tstrscpy(info-\u003edriver, XGMAC_ETHTOOL_NAME, sizeof(info-\u003edriver));\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c=350=static int stmmac_ethtool_get_regs_len(struct net_device dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-353-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c:354:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-355-\t\treturn XGMAC_REGSIZE 4;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c=361=static void stmmac_ethtool_gregs(struct net_device dev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-375-\t\t NUM_DWMAC4_DMA_REGS 4);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c:376:\t} else if (priv-\u003eplat-\u003ecore_type != DWMAC_CORE_XGMAC) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-377-\t\tmemcpy(\u0026reg_space[ETHTOOL_DMA_OFFSET],\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=642=static int stmmac_hwtstamp_set(struct net_device dev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-758-\t\t\tif (priv-\u003esynopsys_id \u003c DWMAC_CORE_3_70 \u0026\u0026\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:759:\t\t\t priv-\u003eplat-\u003ecore_type != DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-760-\t\t\t\tts_event_en = PTP_TCR_TSEVNTENA;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=6605=static int stmmac_dma_cap_show(struct seq_file seq, void v)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6640-\t\t (priv-\u003edma_cap.half_duplex) ? \"Y\" : \"N\");\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6641:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6642-\t\tseq_printf(seq,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6664-\t\t (priv-\u003edma_cap.atime_stamp) ? \"Y\" : \"N\");\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6665:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6666-\t\tseq_printf(seq, \"\\tTimestamp System Time Source: %s\\n\",\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6673-\tif (priv-\u003esynopsys_id \u003e= DWMAC_CORE_4_00 \|\|\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6674:\t priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6675-\t\tseq_printf(seq, \"\\tIP Checksum Offload in RX: %s\\n\",\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7402=static void stmmac_print_actphyif(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7417-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7418:\tcase DWMAC_CORE_XGMAC:\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7419-\t\tphyif_table = stmmac_dwxgmac_phyif;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7444=static int stmmac_hw_init(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7566-\tif ((priv-\u003esynopsys_id \u003e= DWMAC_CORE_3_50 \|\|\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7567:\t priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC) \u0026\u0026\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7568-\t !priv-\u003eplat-\u003eriwt_off) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7833=static int __stmmac_dvr_probe(struct device device,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8040-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8041:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8042-\t\tndev-\u003emax_mtu = XGMAC_JUMBO_LEN;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c=536=static u32 stmmac_clk_csr_set(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c-554-\t\trates = stmmac_sun8i_csr_to_mdc;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:555:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c-556-\t\trates = stmmac_xgmac_csr_to_mdc;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c=595=int stmmac_mdio_register(struct net_device ndev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c-621-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:622:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c-623-\t\tnew_bus-\u003eread = \u0026stmmac_xgmac2_mdio_read_c22;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c-665-\t/* Looks like we need a dummy read for XGMAC only and C45 PHYs /\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:666:\tif (priv-\u003eplat-\u003ecore_type == DWMAC_CORE_XGMAC)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c-667-\t\tstmmac_xgmac2_mdio_read_c45(new_bus, 0, 0, 0);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c=416=stmmac_probe_config_dt(struct platform_device pdev, u8 *mac)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-547-\tif (of_device_is_compatible(np, \"snps,dwxgmac\")) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:548:\t\tplat-\u003ecore_type = DWMAC_CORE_XGMAC;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-549-\t\tplat-\u003epmt = true;\n--\ninclude/linux/stmmac.h=191=enum dwmac_core_type {\n--\ninclude/linux/stmmac.h-194-\tDWMAC_CORE_GMAC4,\ninclude/linux/stmmac.h:195:\tDWMAC_CORE_XGMAC,\ninclude/linux/stmmac.h-196-};\n" }
15/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23681 output: 49 thoughts: 187 Thoughts: Analyzing the DWMAC Core Type Assignment Alright, let's break this down. It looks like `DWMAC_CORE_XGMAC` is explicitly linked to the `dwmac-socfpga.c` and `dwmac-tegra.c` drivers, and also pops up when the device tree compatible string is `"snps,dwxgmac"`. My immediate question is around `stmmac_pci`. I'm going through the code and I'm not seeing any direct assignment of `core_type = DWMAC_CORE_XGMAC` there. That seems odd, because `stmmac_hwif_find` does check the `core_type` in conjunction with `dev_id`. Hmmm. Okay, I see it now. `stmmac_hwif_init` gets the `core_type` via `priv->plat->core_type`. So the critical question is where is that being initialized? If `stmmac_pci` isn't setting it directly, I need to know where `priv->plat->core_type` is populated, or is it zero. If it isn't set, then that defaults to `DWMAC_CORE_MAC` which would explain the lack of an explicit `XGMAC` designation. I'm going to take another look at `stmmac_pci.c` to trace where `priv->plat->core_type` comes from.
16/2	2026/08/14 06:36	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c", "FirstLine": 30, "LineCount": 50 } Results: { "Contents": " 30:\t\tplat-\u003emdio_bus_data-\u003eneeds_reset = true;\n 31:\t}\n 32:\t\n 33:\tstatic int stmmac_default_data(struct pci_dev pdev,\n 34:\t\t\t\t struct plat_stmmacenet_data plat)\n 35:\t{\n 36:\t\t/* Set common default data first /\n 37:\t\tcommon_default_data(plat);\n 38:\t\n 39:\t\tplat-\u003ebus_id = 1;\n 40:\t\tplat-\u003ephy_addr = 0;\n 41:\t\tplat-\u003ephy_interface = PHY_INTERFACE_MODE_GMII;\n 42:\t\n 43:\t\tplat-\u003edma_cfg-\u003epbl = 32;\n 44:\t\tplat-\u003edma_cfg-\u003epblx8 = true;\n 45:\t\t/ TODO: AXI /\n 46:\t\n 47:\t\treturn 0;\n 48:\t}\n 49:\t\n 50:\tstatic const struct stmmac_pci_info stmmac_pci_info = {\n 51:\t\t.setup = stmmac_default_data,\n 52:\t};\n 53:\t\n 54:\tstatic int snps_gmac5_default_data(struct pci_dev pdev,\n 55:\t\t\t\t\t struct plat_stmmacenet_data plat)\n 56:\t{\n 57:\t\tint i;\n 58:\t\n 59:\t\tplat-\u003eclk_csr = STMMAC_CSR_250_300M;\n 60:\t\tplat-\u003ecore_type = DWMAC_CORE_GMAC4;\n 61:\t\tplat-\u003eforce_sf_dma_mode = true;\n 62:\t\tplat-\u003eflags \|= STMMAC_FLAG_TSO_EN;\n 63:\t\tplat-\u003epmt = true;\n 64:\t\n 65:\t\t/ Set default number of RX and TX queues to use */\n 66:\t\tplat-\u003etx_queues_to_use = 4;\n 67:\t\tplat-\u003erx_queues_to_use = 4;\n 68:\t\n 69:\t\tplat-\u003etx_sched_algorithm = MTL_TX_ALGORITHM_WRR;\n 70:\t\tfor (i = 0; i \u003c plat-\u003etx_queues_to_use; i++) {\n 71:\t\t\tplat-\u003etx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;\n 72:\t\t\tplat-\u003etx_queues_cfg[i].weight = 25;\n 73:\t\t\tif (i \u003e 0)\n 74:\t\t\t\tplat-\u003etx_queues_cfg[i].tbs_en = 1;\n 75:\t\t}\n 76:\t\n 77:\t\tplat-\u003erx_sched_algorithm = MTL_RX_ALGORITHM_SP;\n 78:\t\tfor (i = 0; i \u003c plat-\u003erx_queues_to_use; i++)\n 79:\t\t\tplat-\u003erx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;\n" }
17/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25044 output: 46 thoughts: 104 Thoughts: Analyzing the STMMAC Driver Initialization Okay, so I'm digging into this `stmmac_pci.c` file and trying to understand how it's setting up the driver. I see it sets `DWMAC_CORE_GMAC4` for `snps_gmac5_default_data`. Hmm, that seems straightforward enough at first glance. But hang on, something's not quite right... I can't find any mention of `DWMAC_CORE_XGMAC` in this particular file. That's a bit of a head-scratcher. Now, wait a minute, I remember that `stmmac_hwif_init` is responsible for grabbing the hardware version. Okay, let's revisit `stmmac_hwif_init` and get a clearer picture of how it all ties together and how the core is actually identified. I need to understand how the hardware version interacts with these core definitions.
18/2	2026/08/14 06:36	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/hwif.c", "FirstLine": 315, "LineCount": 50 } Results: { "Contents": " 315:\t}\n 316:\t\n 317:\tint stmmac_hwif_init(struct stmmac_priv priv)\n 318:\t{\n 319:\t\tenum dwmac_core_type core_type = priv-\u003eplat-\u003ecore_type;\n 320:\t\tconst struct stmmac_hwif_entry entry;\n 321:\t\tstruct stmmac_version version;\n 322:\t\tstruct mac_device_info mac;\n 323:\t\tbool needs_setup = true;\n 324:\t\tint ret;\n 325:\t\n 326:\t\tstmmac_get_version(priv, \u0026version);\n 327:\t\n 328:\t\t/ Save ID for later use /\n 329:\t\tpriv-\u003esynopsys_id = version.snpsver;\n 330:\t\n 331:\t\tmac = devm_kzalloc(priv-\u003edevice, sizeof(mac), GFP_KERNEL);\n 332:\t\tif (!mac)\n 333:\t\t\treturn -ENOMEM;\n 334:\t\n 335:\t\t/* Check for HW specific setup first /\n 336:\t\tif (priv-\u003eplat-\u003emac_setup) {\n 337:\t\t\tret = priv-\u003eplat-\u003emac_setup(priv, mac);\n 338:\t\t\tif (ret)\n 339:\t\t\t\treturn ret;\n 340:\t\n 341:\t\t\tneeds_setup = false;\n 342:\t\t}\n 343:\t\n 344:\t\tspin_lock_init(\u0026mac-\u003eirq_ctrl_lock);\n 345:\t\n 346:\t\t/ Fallback to generic HW /\n 347:\t\n 348:\t\t/ Use synopsys_id var because some setups can override this /\n 349:\t\tentry = stmmac_hwif_find(core_type, priv-\u003esynopsys_id, version.dev_id);\n 350:\t\tif (!entry) {\n 351:\t\t\tdev_err(priv-\u003edevice,\n 352:\t\t\t\t\"Failed to find HW IF (id=0x%x, gmac=%d/%d)\\n\",\n 353:\t\t\t\tversion.snpsver, core_type == DWMAC_CORE_GMAC,\n 354:\t\t\t\tcore_type == DWMAC_CORE_GMAC4);\n 355:\t\n 356:\t\t\treturn -EINVAL;\n 357:\t\t}\n 358:\t\n 359:\t\t/ Only use generic HW helpers if needed */\n 360:\t\tmac-\u003edesc = mac-\u003edesc ? : entry-\u003edesc;\n 361:\t\tmac-\u003edma = mac-\u003edma ? : entry-\u003edma;\n 362:\t\tmac-\u003emac = mac-\u003emac ? : entry-\u003emac;\n 363:\t\tmac-\u003eptp = mac-\u003eptp ? : entry-\u003ehwtimestamp;\n 364:\t\tmac-\u003emode = mac-\u003emode ? : entry-\u003emode;\n" }
19/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26175 output: 50 thoughts: 244 Thoughts: Analyzing the `stmmac` Driver's XGMAC Behavior Okay, so I'm digging into this `stmmac` driver code, specifically how it handles XGMAC cores. I see that `stmmac_hwif_init` calls `stmmac_hwif_find`, and it uses `priv->plat->core_type` to find the correct hardware interface. The interesting bit is that if `core_type` isn't `DWMAC_CORE_XGMAC`, it's not going to match anything, right? Then my brain clicks: `dwmac-socfpga.c` and `dwmac-tegra.c` both do set `core_type = DWMAC_CORE_XGMAC`. I need to confirm whether these drivers are even reachable in the QEMU environment I'm using. My suspicion, though, is that the issue isn't limited to specific board configs. Then I noticed that `stmmac_main.c` has also been modified. The patch is changing the way the datapath is torn down using `stmmac_datapath_teardown(priv)`. This function is being called in several places: `__stmmac_release`, `stmmac_xdp_release`, and `stmmac_suspend`. Here's the kicker: this teardown logic seems to be executed for all `stmmac` devices, not just the XGMAC ones. That's a red flag. I need to take a closer look at what `stmmac_datapath_teardown` is actually doing in the patch.
20/2	2026/08/14 06:36	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/stmmac_main.c", "FirstLine": 2560, "LineCount": 50 } Results: { "Contents": "2560:\t\t\tstmmac_deinit_chan(priv, priv-\u003eioaddr, chan);\n2561:\t}\n2562:\t\n2563:\t/*\n2564:\t stmmac_datapath_teardown - ordered datapath teardown as per IP specification\n2565:\t * @priv: driver private structure\n2566:\t * Description:\n2567:\t * When teardown ops are available, follow the databook ordered teardown\n2568:\t * sequence.\n2569:\t * Follows the legacy stop + MAC disable for variants without the feature.\n2570:\t /\n2571:\tstatic void stmmac_datapath_teardown(struct stmmac_priv priv)\n2572:\t{\n2573:\t\tu32 rx_channels_count = priv-\u003eplat-\u003erx_queues_to_use;\n2574:\t\tu32 tx_channels_count = priv-\u003eplat-\u003etx_queues_to_use;\n2575:\t\tu32 chan;\n2576:\t\n2577:\t\t/* Stop all TX DMA channels /\n2578:\t\tfor (chan = 0; chan \u003c tx_channels_count; chan++)\n2579:\t\t\tstmmac_stop_tx_dma(priv, chan);\n2580:\t\n2581:\t\t/ Wait for every TX DMA channel to report itself stopped /\n2582:\t\tif (priv-\u003ehw-\u003edma-\u003etx_dma_stopped)\n2583:\t\t\tfor (chan = 0; chan \u003c tx_channels_count; chan++)\n2584:\t\t\t\tstmmac_tx_dma_stopped(priv, priv-\u003eioaddr, chan);\n2585:\t\n2586:\t\t/ Wait for the MTL TX queues to finish pushing into the MAC /\n2587:\t\tif (priv-\u003ehw-\u003edma-\u003etx_mtl_drain)\n2588:\t\t\tfor (chan = 0; chan \u003c tx_channels_count; chan++)\n2589:\t\t\t\tstmmac_tx_mtl_drain(priv, priv-\u003eioaddr, chan);\n2590:\t\n2591:\t\t/ Disable the MAC TX and RX /\n2592:\t\tstmmac_mac_set(priv, priv-\u003eioaddr, false);\n2593:\t\n2594:\t\t/ Wait for the MTL RX queues to drain into the RX DMA /\n2595:\t\tif (priv-\u003ehw-\u003edma-\u003erx_mtl_drain)\n2596:\t\t\tfor (chan = 0; chan \u003c rx_channels_count; chan++)\n2597:\t\t\t\tstmmac_rx_mtl_drain(priv, priv-\u003eioaddr, chan);\n2598:\t\n2599:\t\t/ Stop all RX DMA channels /\n2600:\t\tfor (chan = 0; chan \u003c rx_channels_count; chan++)\n2601:\t\t\tstmmac_stop_rx_dma(priv, chan);\n2602:\t\n2603:\t\t/ Wait for every RX DMA channel to report itself stopped /\n2604:\t\tif (priv-\u003ehw-\u003edma-\u003erx_dma_stopped)\n2605:\t\t\tfor (chan = 0; chan \u003c rx_channels_count; chan++)\n2606:\t\t\t\tstmmac_rx_dma_stopped(priv, priv-\u003eioaddr, chan);\n2607:\t}\n2608:\t\n2609:\t/*\n" }
21/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 27717 output: 19 thoughts: 1288 Thoughts: Analysis of stmmac Datapath Teardown and Implications Okay, so I'm looking at this `stmmac_datapath_teardown` function, and it seems to be universally called across all devices that use this driver. The interesting part is the change in its behavior. Previously, the DMA was stopped with `stmmac_stop_all_dma` and the MAC was disabled using `stmmac_mac_set(..., false)`. Now, `stmmac_datapath_teardown` directly calls `stmmac_stop_tx_dma`, then `stmmac_mac_set(..., false)`, and finally `stmmac_stop_rx_dma`. This order is a functional change affecting all stmmac devices. This difference in execution flow is a concern. Moreover, the original teardown order included disabling the MAC after freeing the DMA descriptors. The new order disables the MAC before freeing them, which is a major shift. The implications here are significant; a change in resource release order is a potential recipe for instability, especially during bring-down scenarios (e.g., `ip link set eth0 down`). The same changes have been made to `stmmac_hw_setup` and `stmmac_xdp_open`, switching the order of MAC enable and DMA start. So, now the DMA starts before MAC is enabled. I've confirmed that `stmmac_datapath_teardown` is reached via `__stmmac_release`, `stmmac_xdp_release`, and `stmmac_suspend`. This means these changes hit all interfaces using this driver, which are potentially reachable through the `stmmac_pci` driver. I'm also seeing these new `dwxgmac2_*` functions. Those are only reached when `core_type == DWMAC_CORE_XGMAC`. I need to figure out how to ensure that condition is met in my tests. It looks like the `stmmac_pci` driver uses `stmmac_pci_info` to configure the device, and that structure has a `core_type` field. The PCI ID table lists an `XGMAC_ID`. This is promising. I need to figure out what that `XGMAC_ID` actually is in the context of `pci_device_id`. Can I reach the new functions? The question is, how do I ensure a PCI device gets bound to this `XGMAC_ID`? If I can, then I can reach the new functions that implement the change.
22/2	2026/08/14 06:36	tool	grepper	0m Args: { "Expression": "XGMAC_ID" } Results: { "Output": "drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c=985=static int hns_mac_get_mode(phy_interface_t phy_if)\n--\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c-990-\tcase PHY_INTERFACE_MODE_XGMII:\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:991:\t\treturn MAC_XGMAC_IDX;\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c-992-\tdefault:\n--\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h=15=struct dsaf_device;\n--\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h-32-#define MAC_GMAC_IDX 0\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h:33:#define MAC_XGMAC_IDX 1\ndrivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h-34-\n--\ndrivers/net/ethernet/stmicro/stmmac/common.h-45-/* Device ID /\ndrivers/net/ethernet/stmicro/stmmac/common.h:46:#define DWXGMAC_ID\t\t0x76\ndrivers/net/ethernet/stmicro/stmmac/common.h-47-#define DWXLGMAC_ID\t\t0x27\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h-184-#define XGMAC_L3L4_ADDR_CTRL\t\t0x00000c00\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h:185:#define XGMAC_IDDR\t\t\tGENMASK(16, 8)\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h:186:#define XGMAC_IDDR_FNUM_MASK\t\tGENMASK(7, 4)\t/ FNUM within IDDR /\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h:187:#define XGMAC_IDDR_REG_MASK\t\tGENMASK(3, 0)\t/ REG within IDDR /\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2.h-188-#define XGMAC_TT\t\t\tBIT(1)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c=1241=static int dwxgmac2_filter_read(struct mac_device_info hw, u32 filter_no,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c-1251-\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1252:\tiddr = FIELD_PREP(XGMAC_IDDR_FNUM_MASK, filter_no) \|\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1253:\t FIELD_PREP(XGMAC_IDDR_REG_MASK, reg);\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1254:\tvalue = FIELD_PREP(XGMAC_IDDR, iddr);\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c-1255-\tvalue \|= XGMAC_TT \| XGMAC_XB;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c=1266=static int dwxgmac2_filter_write(struct mac_device_info *hw, u32 filter_no,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c-1278-\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1279:\tiddr = FIELD_PREP(XGMAC_IDDR_FNUM_MASK, filter_no) \|\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1280:\t FIELD_PREP(XGMAC_IDDR_REG_MASK, reg);\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:1281:\tvalue = FIELD_PREP(XGMAC_IDDR, iddr);\ndrivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c-1282-\tvalue \|= XGMAC_XB;\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c=111=static const struct stmmac_hwif_entry {\n--\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-249-\t\t.min_id = DWXGMAC_CORE_2_10,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c:250:\t\t.dev_id = DWXGMAC_ID,\ndrivers/net/ethernet/stmicro/stmmac/hwif.c-251-\t\t.regs = {\n" }
23/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 30954 output: 45 thoughts: 218 Thoughts: Analyzing the Device ID and Version Retrieval Okay, so I see that `DWXGMAC_ID` is defined as `0x76`. That seems like a potential identifier for the XGMAC core. However, I need to understand how the driver actually determines the device ID and version at runtime. The `stmmac_hwif_init` function looks like the key entry point here. I recall that this function leverages hardware registers to determine the version. The code snippet for `stmmac_get_version` is what I need to focus on. It reads from the `MAC_VERSION` register. The function then extracts relevant fields using `FIELD_GET`, namely `DWMAC_SNPSVER` and `DWMAC_USERVER`. If `core_type` is an XGMAC, it gets the version from `DWMAC_USERVER` else it uses the `DWMAC_SNPSVER`. I'm now thinking about `core_type`. Where does the `core_type` variable come from? Is it passed into `stmmac_get_version`? No, it looks like `core_type` is a local variable to `stmmac_hwif_init`. I'll need to double-check that this is accurate. I should scrutinize `stmmac_hwif_init` to confirm how `core_type` is determined and set before it's used by `stmmac_get_version`. Understanding how `core_type` is set is critical for interpreting the device version correctly.
24/2	2026/08/14 06:36	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/hwif.c", "FirstLine": 21, "LineCount": 50 } Results: { "Contents": " 21:\tstatic void stmmac_get_version(struct stmmac_priv priv,\n 22:\t\t\t\t struct stmmac_version ver)\n 23:\t{\n 24:\t\tenum dwmac_core_type core_type = priv-\u003eplat-\u003ecore_type;\n 25:\t\tunsigned int version_offset;\n 26:\t\tu32 version;\n 27:\t\n 28:\t\tver-\u003esnpsver = 0;\n 29:\t\tver-\u003edev_id = 0;\n 30:\t\n 31:\t\tif (core_type == DWMAC_CORE_MAC100)\n 32:\t\t\treturn;\n 33:\t\n 34:\t\tif (core_type == DWMAC_CORE_GMAC)\n 35:\t\t\tversion_offset = GMAC_VERSION;\n 36:\t\telse\n 37:\t\t\tversion_offset = GMAC4_VERSION;\n 38:\t\n 39:\t\tversion = readl(priv-\u003eioaddr + version_offset);\n 40:\t\tif (version == 0) {\n 41:\t\t\tdev_info(priv-\u003edevice, \"Version ID not available\\n\");\n 42:\t\t\treturn;\n 43:\t\t}\n 44:\t\n 45:\t\tdev_info(priv-\u003edevice, \"User ID: 0x%x, Synopsys ID: 0x%x\\n\",\n 46:\t\t\t FIELD_GET(DWMAC_USERVER, version),\n 47:\t\t\t FIELD_GET(DWMAC_SNPSVER, version));\n 48:\t\n 49:\t\tver-\u003esnpsver = FIELD_GET(DWMAC_SNPSVER, version);\n 50:\t\tif (core_type == DWMAC_CORE_XGMAC)\n 51:\t\t\tver-\u003edev_id = FIELD_GET(DWMAC_USERVER, version);\n 52:\t}\n 53:\t\n 54:\tstatic void stmmac_dwmac_mode_quirk(struct stmmac_priv priv)\n 55:\t{\n 56:\t\tstruct mac_device_info mac = priv-\u003ehw;\n 57:\t\n 58:\t\tif (priv-\u003echain_mode) {\n 59:\t\t\tdev_info(priv-\u003edevice, \"Chain mode enabled\\n\");\n 60:\t\t\tpriv-\u003edescriptor_mode = STMMAC_CHAIN_MODE;\n 61:\t\t\tmac-\u003emode = \u0026chain_mode_ops;\n 62:\t\t} else {\n 63:\t\t\tdev_info(priv-\u003edevice, \"Ring mode enabled\\n\");\n 64:\t\t\tpriv-\u003edescriptor_mode = STMMAC_RING_MODE;\n 65:\t\t\tmac-\u003emode = \u0026ring_mode_ops;\n 66:\t\t}\n 67:\t}\n 68:\t\n 69:\tstatic int stmmac_dwmac1_quirks(struct stmmac_priv *priv)\n 70:\t{\n" }
25/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 32307 output: 45 thoughts: 127 Thoughts: Analyzing the stmmac Version Retrieval Okay, so I'm looking at how `stmmac_get_version` works. It's pulling the `core_type` from the `priv->plat` structure. Right, and that `priv->plat` is set up during the binding process. I'm thinking about Syzkaller and how it interacts with this. When Syzkaller uses `stmmac_pci`, it goes through `stmmac_pci_info`, and that's where the `core_type` is set. It seems like it's being set to either `DWMAC_CORE_GMAC4` or `0`, which is aliased to `DWMAC_CORE_GMAC`. That's interesting, but I need to make sure I'm not missing anything. My primary concern is to ensure the syzkaller test coverage is sound. The thing that I am missing is the `DWMAC_CORE_XGMAC` value! Is there any PCI ID configuration that causes `core_type` to be set to `DWMAC_CORE_XGMAC`? I need to double-check `stmmac_pci.c` to be completely thorough.
26/2	2026/08/14 06:36	tool	grepper	0m Error: no matches Args: { "Expression": "XGMAC", "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c" } Results: { "error": "no matches" }
27/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 32760 output: 43 thoughts: 31 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Investigating the XGMAC Absence Hmm, interesting. My initial hunch was that the `XGMAC` module was part of the standard STMMAC driver, but a quick check reveals that `stmmac_pci.c` doesn't actually contain the symbol. That's a key piece of information, and it means I need to adjust my search strategy. Where else could it be hiding, or potentially, under a slightly different name? My immediate next step is to explore the "dwmac-intel.c" file. Intel is a big player in this space, and they often implement their own specific versions of these drivers. The XGMAC implementation, if present at all, might be tucked away in there. I'll need to scrutinize that file carefully, looking for anything that sounds like a related implementation.
28/2	2026/08/14 06:36	tool	grepper	0m Error: no matches Args: { "Expression": "XGMAC", "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c" } Results: { "error": "no matches" }
29/2	2026/08/14 06:36	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33044 output: 45 thoughts: 13 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person: Navigating the Loongson DWMAC Driver Okay, I'm thinking about the DWMAC driver specifically for Loongson. My mental map is going straight to `dwmac-loongson.c`. That's where I need to start. It's the point of integration, where the generic DWMAC code interfaces with the Loongson-specific hardware. I'm immediately trying to recall: what are the key differences between the generic DWMAC framework and the Loongson SoC's implementation? Clock management? DMA configuration? Interrupt handling specific to the Loongson platform? Memory mapping? Power management? I need to quickly refresh my understanding of how the Loongson architecture interacts with the standard DWMAC registers and structures. I'm anticipating that I'll be looking for any non-standard register accesses or interrupt handling routines within that file. I expect to find some critical initialization code within this file for the given hardware. Ultimately, I'm trying to figure out how this `dwmac-loongson.c` file integrates with the rest of the DWMAC stack, and what custom Loongson-specific bits are handled there.
30/2	2026/08/14 06:37	tool	grepper	0m Error: no matches Args: { "Expression": "XGMAC", "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c" } Results: { "error": "no matches" }
31/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33390 output: 44 thoughts: 12 Thoughts: Here's my summary, as though I were pondering this: Considering the `dwmac-motorcomm.c` Driver Okay, so I'm thinking about Ethernet drivers, particularly in the context of this specific system, and the `dwmac-motorcomm.c` driver is poking at the front of my mind. What's the deal with this particular implementation? Is it doing anything special or unique that I need to be aware of? I need to analyze how it handles the MAC's communication. Are there any deviations from the standard DesignWare MAC driver? Does it contain any Motorcomm-specific hardware quirks, or are they handled upstream? I have to consider the performance implications here, especially if it's interacting with any custom hardware or a non-standard PHY. Let me dive into the code and see what stands out. I need to keep an eye out for potential interrupt handling differences, DMA setup that is optimized, and any power management considerations specific to this driver and its integration.
32/2	2026/08/14 06:37	tool	grepper	0m Error: no matches Args: { "Expression": "XGMAC", "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c" } Results: { "error": "no matches" }
33/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33668 output: 50 thoughts: 277 Thoughts: My Analysis of the DWMAC/STMMAC Driver Interaction Okay, so I'm digging into this, and it seems pretty clear that `DWMAC_CORE_XGMAC` isn't accessible through PCI. That's not a surprise; it's a platform device, likely configured at boot by something like `dwmac-socfpga.c`, `dwmac-tegra.c`, or `stmmac_platform.c`. The question is, can Syzkaller emulate those platform devices effectively? I know it can inject device tree nodes, assuming it has a function like `syz_init_net_socket` or something similar available, but usually, it won't dynamically create platform devices unless there's a specific pseudo-syscall designed for that purpose, or if it's baked into the initial QEMU image. Hold on... This patch is touching `stmmac_main.c`. That's the core driver for all STMMAC devices, including things like `DWMAC_CORE_GMAC4` and `DWMAC_CORE_GMAC`. That's a key observation. Now I need to figure out if `stmmac_datapath_teardown` gets called for `DWMAC_CORE_GMAC4`. It's essential to understand the scope of this change. Okay, I've checked the code, and yes, `stmmac_datapath_teardown` is definitely called in functions like `__stmmac_release`, `stmmac_xdp_release`, and `stmmac_suspend`. Good. And these functions are called for all stmmac devices, regardless of the specific `core_type`. This is the confirmation I needed: it seems the function does apply to multiple devices and isn't specific to `DWMAC_CORE_XGMAC`. I need to verify that once more. But it looks like I understand the flow of events here and the impact of the patch.
34/2	2026/08/14 06:37	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/stmmac_main.c", "FirstLine": 4280, "LineCount": 50 } Results: { "Contents": "4280:\t\tkfree(dma_conf);\n4281:\t\treturn ret;\n4282:\t}\n4283:\t\n4284:\tstatic void __stmmac_release(struct net_device dev)\n4285:\t{\n4286:\t\tstruct stmmac_priv priv = netdev_priv(dev);\n4287:\t\tu8 chan;\n4288:\t\n4289:\t\tstmmac_disable_all_queues(priv);\n4290:\t\n4291:\t\tfor (chan = 0; chan \u003c priv-\u003eplat-\u003etx_queues_to_use; chan++)\n4292:\t\t\thrtimer_cancel(\u0026priv-\u003edma_conf.tx_queue[chan].txtimer);\n4293:\t\n4294:\t\tnetif_tx_disable(dev);\n4295:\t\n4296:\t\t/* Free the IRQ lines /\n4297:\t\tstmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);\n4298:\t\n4299:\t\t/ Has to run before mac_link_down() disables the MAC. /\n4300:\t\tstmmac_datapath_teardown(priv);\n4301:\t\n4302:\t\t/ Stop and disconnect the PHY /\n4303:\t\tphylink_stop(priv-\u003ephylink);\n4304:\t\n4305:\t\t/ Release and free the Rx/Tx resources /\n4306:\t\tfree_dma_desc_resources(priv, \u0026priv-\u003edma_conf);\n4307:\t\n4308:\t\tstmmac_release_ptp(priv);\n4309:\t\n4310:\t\tif (stmmac_fpe_supported(priv))\n4311:\t\t\tethtool_mmsv_stop(\u0026priv-\u003efpe_cfg.mmsv);\n4312:\t}\n4313:\t\n4314:\t/\n4315:\t stmmac_release - close entry point of the driver\n4316:\t * @dev : device pointer.\n4317:\t * Description:\n4318:\t * This is the stop entry point of the driver.\n4319:\t /\n4320:\tstatic int stmmac_release(struct net_device dev)\n4321:\t{\n4322:\t\tstruct stmmac_priv priv = netdev_priv(dev);\n4323:\t\n4324:\t\t/ If the PHY or MAC has WoL enabled, then the PHY will not be\n4325:\t\t * suspended when phylink_stop() is called below. Set the PHY\n4326:\t\t * to its slowest speed to save power.\n4327:\t\t */\n4328:\t\tif (device_may_wakeup(priv-\u003edevice))\n4329:\t\t\tphylink_speed_down(priv-\u003ephylink, false);\n" }
35/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 35206 output: 20 thoughts: 922 Thoughts: Analyzing the STMMAC Datapath Teardown and Setup Okay, so I've confirmed that `__stmmac_release` calls `stmmac_datapath_teardown(priv)`. Let's break down what's happening in `stmmac_datapath_teardown`. It appears to be a multi-channel DMA shutdown sequence. It iterates through the configured TX and RX queues, stopping the DMA channels, waiting for them to report they're stopped, draining MTL queues, disabling the MAC, and then repeating the process for RX channels. A key point is the conditional check `priv->hw->dma->tx_dma_stopped`. For a GMAC4, this will be NULL, because only `dwxgmac210_dma_ops` provides it, and the wait is skipped, which is probably okay. Now here is where things get interesting: the order of operations in this teardown, specifically the relative position of `stmmac_stop_tx_dma`, `stmmac_mac_set`, and `stmmac_stop_rx_dma`, has been altered. This is a functional change. Previously it was: 1. `stmmac_stop_rx_dma` 2. `stmmac_stop_tx_dma` 3. `stmmac_mac_set(..., false)` Now it's: 1. `stmmac_stop_tx_dma` 2. `stmmac_mac_set(..., false)` 3. `stmmac_stop_rx_dma` Also, in `stmmac_hw_setup` and `stmmac_xdp_open`, the order of `stmmac_mac_set(..., true)` and `stmmac_start_all_dma` has been swapped: Previously: 1. `stmmac_mac_set(..., true)` 2. `stmmac_start_all_dma` Now: 1. `stmmac_start_all_dma` 2. `stmmac_mac_set(..., true)` Since this change impacts the behavior of all stmmac devices, and especially those accessible through PCI in something like QEMU, this warrants immediate fuzzing. It has a real potential to break things and expose any timing or resource management issues. It is important to confirm the config options, `CONFIG_STMMAC_ETH` and `CONFIG_STMMAC_PCI`. I want to see if the fuzzing can expose any issues that may arise from this reordering of calls, or even from the skipped wait.
36/2	2026/08/14 06:37	tool	grepper	0m Args: { "Expression": "config STMMAC_ETH" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:2:config STMMAC_ETH\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-3-\ttristate \"STMicroelectronics Multi-Gigabit Ethernet driver\"\n" }
37/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 36837 output: 20 thoughts: 13 Thoughts: Here's my take on those thoughts, tailored for an expert audience: Analyzing the STMMAC PCI Configuration Okay, so the initial thought is, naturally, to verify the state of `CONFIG_STMMAC_PCI`. My instinct is to quickly assess its current setting, understanding that this flag directly governs the inclusion of the Synopsys STMMAC Ethernet driver for PCI-based network interfaces. I'm likely gearing up for a deeper dive into kernel configuration, debugging a network issue, or perhaps even preparing to enable STMMAC on a new hardware platform. The immediate question in my mind is: is it enabled as a module (M), built-in (Y), or disabled (N)? That's the first data point I need to establish. I need to know where I am with this module.
38/2	2026/08/14 06:37	tool	grepper	0m Args: { "Expression": "config STMMAC_PCI" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/Kconfig=398=config DWMAC_MOTORCOMM\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-406-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:407:config STMMAC_PCI\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-408-\ttristate \"STMMAC PCI bus support\"\n" }
39/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 37168 output: 44 thoughts: 14 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: Analyzing the STMMAC_PCI Dependencies Alright, let's dive in. My immediate thought is, "Okay, `STMMAC_PCI`... what's it tied to?" I need to quickly map out the dependencies. I'm going to mentally run through the likely candidates: PCI bus driver, obviously, but what specific PCI registers is it leveraging? Are there any platform-specific quirks or variations depending on the system-on-a-chip (SoC) it's running on? I have to look for indirect dependencies as well - DMA engines, interrupt controllers, clock management. Are we dealing with any shared resources that could cause conflicts? I'll also be mindful of potential interactions with other networking drivers on the system. Is there an interaction that could occur that could affect other drivers on the system? I need to understand the implications of any dependency changes if there are any, and consider this in my analysis. What kernel versions is this module designed to work with? Any known compatibility issues? I have to be aware of the overall system context to prevent any issues. Let's make sure we have a solid understanding of the implications of any dependencies on the system.
40/2	2026/08/14 06:37	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/Kconfig", "FirstLine": 400, "LineCount": 20 } Results: { "Contents": " 400:\t\tdepends on PCI\n 401:\t\tselect MOTORCOMM_PHY\n 402:\t\tselect STMMAC_LIBPCI\n 403:\t\thelp\n 404:\t\t This enables glue driver for Motorcomm DWMAC-based PCI Ethernet\n 405:\t\t controllers. Currently only YT6801 is supported.\n 406:\t\n 407:\tconfig STMMAC_PCI\n 408:\t\ttristate \"STMMAC PCI bus support\"\n 409:\t\tdepends on PCI\n 410:\t\tdepends on COMMON_CLK\n 411:\t\tselect STMMAC_LIBPCI\n 412:\t\thelp\n 413:\t\t This selects the platform specific bus support for the stmmac driver.\n 414:\t\t This driver was tested on XLINX XC2V3000 FF1152AMT0221\n 415:\t\t D1215994A VIRTEX FPGA board and SNPS QoS IPK Prototyping Kit.\n 416:\t\n 417:\t\t If you have a controller with this interface, say Y or M here.\n 418:\t\n 419:\t\t If unsure, say N.\n" }
41/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 37811 output: 42 thoughts: 57 Thoughts: Okay, here's my take on those dependencies, from an expert's perspective: Analyzing STMMAC Driver Dependencies Alright, let's break this down. My initial observation is that `STMMAC_PCI` relies on both `PCI` and `COMMON_CLK`. That's standard for a PCI-based Ethernet controller – needs the PCI infrastructure to exist and clock management to function correctly. No surprises there. Next, we see that `STMMAC_ETH` depends on `HAS_IOMEM` and `HAS_DMA`. This is what I'd expect. `HAS_IOMEM` means it can access memory-mapped I/O, which is crucial for interacting with the Ethernet controller's registers. And `HAS_DMA` indicates it requires DMA (Direct Memory Access) support. A modern Ethernet controller has to use DMA to be performant. It wouldn't be very useful if it didn't. Now, I need to understand this `STMMAC_ETH` dependency better. I want to dive a little deeper to confirm that I'm seeing everything correctly. Let me see what specifically depends on this driver.
42/2	2026/08/14 06:37	tool	read-file	0m Args: { "File": "drivers/net/ethernet/stmicro/stmmac/Kconfig", "FirstLine": 1, "LineCount": 20 } Results: { "Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\tconfig STMMAC_ETH\n 3:\t\ttristate \"STMicroelectronics Multi-Gigabit Ethernet driver\"\n 4:\t\tdepends on HAS_IOMEM \u0026\u0026 HAS_DMA\n 5:\t\tdepends on PTP_1588_CLOCK_OPTIONAL\n 6:\t\tdepends on ETHTOOL_NETLINK\n 7:\t\tselect MII\n 8:\t\tselect PCS_XPCS\n 9:\t\tselect PAGE_POOL\n 10:\t\tselect PHYLINK\n 11:\t\tselect CRC32\n 12:\t\tselect RESET_CONTROLLER\n 13:\t\tselect NET_DEVLINK\n 14:\t\thelp\n 15:\t\t This is the driver for the Ethernet IPs built around a\n 16:\t\t Synopsys IP Core.\n 17:\t\n 18:\tif STMMAC_ETH\n 19:\t\n 20:\tconfig STMMAC_SELFTESTS\n" }
43/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 38414 output: 22 thoughts: 545 Thoughts: Fuzzing Strategy for STMMAC Driver Okay, so I'm looking at this STMMAC driver patch, and my initial thoughts are around configuration options. `STMMAC_ETH` and `STMMAC_PCI` seem to be the primary configurations in this context. I'll need to remember those. What about the other DWMAC configurations – `DWMAC_INTEL`, `DWMAC_LOONGSON`, and `DWMAC_MOTORCOMM`? For now, I'll just focus on including `STMMAC_PCI` and `STMMAC_ETH`, and revisit those if necessary. Now, let's get down to the fuzzing targets. This patch modifies several functions. I need to figure out which ones are critical and where the best entry points are for maximum impact. The patch touches `stmmac_datapath_teardown`, `stmmac_hw_setup`, `stmmac_xdp_open`, `dwxgmac2_tx_dma_stopped`, `dwxgmac2_tx_mtl_drain`, `dwxgmac2_rx_mtl_drain`, and `dwxgmac2_rx_dma_stopped`. I see that `stmmac_datapath_teardown` is a static function, but it is called by `__stmmac_release`, `stmmac_xdp_release`, and `stmmac_suspend`. Also, `stmmac_hw_setup` is also important, as it gets called by `stmmac_open` and `stmmac_resume`. The key entry points appear to be the net_device_ops functions `.ndo_open` and `.ndo_stop`, which correspond to `stmmac_open` and `stmmac_release` respectively. Also, the device PM ops for `stmmac_suspend` and `stmmac_resume` need a deeper dive. And of course, the XDP setup functions: `stmmac_xdp_open` and `stmmac_xdp_release`. So, it looks like `stmmac_open`, `stmmac_release`, `stmmac_suspend`, `stmmac_resume`, `stmmac_xdp_open`, and `stmmac_xdp_release` are the crucial functions for intensive fuzzing. Wait, let me double-check something. `stmmac_datapath_teardown` is static, yes, but it’s called from `__stmmac_release`, which is then called from `stmmac_release`. And `stmmac_open` calls `stmmac_hw_setup`. So it seems `stmmac_open` and `stmmac_release` are still the primary entry points. Along with `stmmac_xdp_open` and `stmmac_xdp_release`, they are the main focus. I'll need to quickly check if `stmmac_xdp_open` itself is static or not.
44/2	2026/08/14 06:37	tool	grepper	0m Args: { "Expression": "stmmac_xdp_open" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac.h=407=void stmmac_ptp_unregister(struct stmmac_priv priv);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h:408:int stmmac_xdp_open(struct net_device dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h-409-void stmmac_xdp_release(struct net_device dev);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7136=void stmmac_xdp_release(struct net_device dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7165-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7166:int stmmac_xdp_open(struct net_device dev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7167-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c=102=int stmmac_xdp_set_prog(struct stmmac_priv priv, struct bpf_prog *prog,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c-134-\tif (if_running \u0026\u0026 need_update)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c:135:\t\tstmmac_xdp_open(dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c-136-\n" }
45/2	2026/08/14 06:37	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 40110 output: 20 thoughts: 51 Thoughts: Okay, here's my take on those functions, thinking through it as you asked: My Perspective on the `stmmac` XDP and Power Management Functions Right, let me see...so, I'm noting that `stmmac_xdp_open` and `stmmac_xdp_release`, those are definitely not declared as `static`. Good, that makes sense for the XDP functionality. They're likely meant to be callable from outside the core `stmmac` module, presumably by XDP programs or some other external component that needs to manage the interaction with the driver in that context. We need that external linkage. And then looking at the suspend and resume routines, `stmmac_suspend` and `stmmac_resume`? Also non-static. Again, as expected. Those are critical entry points for the system power management framework. The power management code, or perhaps even higher-level drivers, needs to be able to call these functions directly to control the power state of the STMMAC device. If they were static, we'd have a real problem integrating with the wider system. That would make for a brittle driver. We can't have that.
46/2	2026/08/14 06:38	tool	grepper	0m Args: { "Expression": "stmmac_suspend" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c=57=static int __maybe_unused tegra_mgbe_suspend(struct device dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c-61-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c:62:\terr = stmmac_suspend(dev);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c-63-\tif (err)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h=411=int stmmac_resume(struct device dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h:412:int stmmac_suspend(struct device dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h-413-void stmmac_dvr_remove(struct device dev);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=8204=EXPORT_SYMBOL_GPL(stmmac_dvr_remove);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8206-/*\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8207: stmmac_suspend - suspend callback\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8208- * @dev: device pointer\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8212- /\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8213:int stmmac_suspend(struct device dev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8214-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8262-}\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8263:EXPORT_SYMBOL_GPL(stmmac_suspend);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8264-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=8394=EXPORT_SYMBOL_GPL(stmmac_resume);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8396-/* This is not the same as EXPORT_GPL_SIMPLE_DEV_PM_OPS() when CONFIG_PM=n */\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8397:DEFINE_SIMPLE_DEV_PM_OPS(stmmac_simple_pm_ops, stmmac_suspend, stmmac_resume);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8398-EXPORT_SYMBOL_GPL(stmmac_simple_pm_ops);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c=1001=const struct dev_pm_ops stmmac_pltfr_pm_ops = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:1002:\tSET_SYSTEM_SLEEP_PM_OPS(stmmac_suspend, stmmac_resume)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-1003-\tSET_RUNTIME_PM_OPS(stmmac_runtime_suspend, stmmac_runtime_resume, NULL)\n" }
47/2	2026/08/14 06:38	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 41428 output: 19 thoughts: 59 Thoughts: Here's my thinking process: Examining the STMMAC Driver's Suspend/Resume Logic Okay, so I see that `stmmac_suspend` and `stmmac_resume` are explicitly exported. That's good, suggests they're designed for external interaction, probably for power management, which is what I'd expect. However, `stmmac_open` and `stmmac_release` are defined within `stmmac_main.c`, and that raises a flag. Wait, hold on a second. I need to be sure about their scope. Let me quickly double-check if those functions are actually declared as `static` within that file, because that would confirm they're only intended for internal use within the driver's core module. Gotta make sure those open/release functions aren't inadvertently being exposed, that's important for the overall architecture.
48/2	2026/08/14 06:38	tool	grepper	0m Args: { "Expression": "stmmac_open" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_main.c=4100=stmmac_setup_dma_desc(struct stmmac_priv priv, unsigned int mtu)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4165-/\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4166: __stmmac_open - open entry point of the driver\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4167- * @dev : pointer to the device structure.\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4174- /\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4175:static int __stmmac_open(struct net_device dev,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4176-\t\t\t struct stmmac_dma_conf dma_conf)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4232-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4233:static int stmmac_open(struct net_device dev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4234-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4260-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4261:\tret = __stmmac_open(dev, dma_conf);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-4262-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=6155=static int stmmac_change_mtu(struct net_device dev, int new_mtu)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6190-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6191:\t\tret = __stmmac_open(dev, dma_conf);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6192-\t\tif (ret) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7347=static const struct net_device_ops stmmac_netdev_ops = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7348:\t.ndo_open = stmmac_open,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7349-\t.ndo_start_xmit = stmmac_xmit,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7634=int stmmac_reinit_queues(struct net_device dev, u8 rx_cnt, u8 tx_cnt)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7653-\tif (netif_running(dev))\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7654:\t\tret = stmmac_open(dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7655-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7659=int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7670-\tif (netif_running(dev))\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7671:\t\tret = stmmac_open(dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7672-\n" }
49/2	2026/08/14 06:38	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 42838 output: 24 thoughts: 208 Thoughts: Analyzing STMMAC Driver Entrypoints for Fuzzing Okay, so I'm looking at how best to target the STMMAC driver with fuzzing, specifically thinking about what entrypoints are most accessible to tools like syzkaller. My initial thought was that `stmmac_open` and `stmmac_release` are static, which generally means they won't be exported as symbols and therefore won't be easily fuzzable. However, I need to remember that syzkaller can focus on static functions if they're not inlined. But, realistically, it's always preferable to leverage non-static API entrypoints for fuzzing. Let's see, the non-static candidates seem to be: `stmmac_suspend`, `stmmac_resume`, `stmmac_xdp_open`, `stmmac_xdp_release`, `stmmac_change_mtu`, `stmmac_reinit_queues`, and `stmmac_reinit_ringparam`. I'm going to have to make a note that `stmmac_change_mtu` is static. Wait a second...I just remembered that `stmmac_reinit_queues` and `stmmac_reinit_ringparam` seem to call `stmmac_open`. If that's the case, then that could be a significant entry point. Let me quickly double-check that those are actually exported symbols.
50/2	2026/08/14 06:38	tool	grepper	0m Error: no matches Args: { "Expression": "EXPORT_SYMBOL.stmmac_reinit" } Results:* { "error": "no matches" }
51/2	2026/08/14 06:38	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 43404 output: 23 thoughts: 16 Thoughts: Okay, let's dive into this. Here's my take on those thoughts, as if they're my own: Examining the `stmmac_reinit_queues` Function Right, let's zero in on `stmmac_reinit_queues`. I need to understand its role. I'm guessing it's a critical function for resetting or re-establishing the transmit and receive queues within the STMMAC driver. Knowing this, it is likely involved in recovering from error conditions or re-configuring the MAC. The purpose of this seems critical for maintaining network functionality and potentially for tasks like link re-negotiation, power management, or even handling device resets. I need to refresh my understanding of how the queues are structured and managed within this specific STMMAC implementation. What are its dependencies? What calls it? And importantly, what are the potential failure modes? I need to think this through carefully, as any bug here could result in serious networking disruption. Time to see what I can find.
52/2	2026/08/14 06:38	tool	grepper	0m Args: { "Expression": "stmmac_reinit_queues" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac.h=414=int stmmac_dvr_probe(struct device device,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h-416-\t\t struct stmmac_resources res);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h:417:int stmmac_reinit_queues(struct net_device dev, u8 rx_cnt, u8 tx_cnt);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h-418-int stmmac_reinit_ringparam(struct net_device dev, u32 rx_size, u32 tx_size);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c=992=static int stmmac_set_channels(struct net_device dev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-1001-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c:1002:\treturn stmmac_reinit_queues(dev, chan-\u003erx_count, chan-\u003etx_count);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c-1003-}\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7613=static void stmmac_napi_del(struct net_device dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7633-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7634:int stmmac_reinit_queues(struct net_device *dev, u8 rx_cnt, u8 tx_cnt)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7635-{\n" }
53/2	2026/08/14 06:38	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 44192 output: 22 thoughts: 184 Thoughts: Analyzing Symbol Visibility in the STMMAC Driver Okay, so I'm trying to figure out which symbols in this STMMAC driver are visible externally and, more importantly, why. I've got a bit of a mental map forming. The initial clue is that some are not exported, but they're also not static, which gives me pause. Makes me think of them as potential candidates for internal calls across driver layers. Now, let's see, what about `stmmac_xdp_open` and `stmmac_xdp_release`? Those are the non-static ones I need to consider more deeply. On the other hand, `stmmac_suspend` and `stmmac_resume` are exported, which is what I would expect for a power management function. And then there are `stmmac_dvr_probe` and `stmmac_dvr_remove`, also exported, which handle device initialization and removal, respectively. Hold on a second, that's it! What happens when the driver is removed? Does `stmmac_dvr_remove` lead to the cleanup function, `stmmac_release`? I seem to remember that `stmmac_release` is a function called via `ndo_stop` which should be called by the netdev unregistration. Okay, I think I've got it. It's the unregistration that is the important action here. So, in terms of analyzing the driver's lifecycle, `stmmac_dvr_remove` is a good symbol to focus on. It unregisters the netdev, which calls `ndo_stop`, which in turn leads to the release and cleanup. I'm going to dig into the implementation of `stmmac_dvr_remove` now. That's the key to understanding this.
54/2	2026/08/14 06:38	tool	grepper	0m Args: { "Expression": "stmmac_dvr_remove" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c=343=static void dwc_eth_dwmac_remove(struct platform_device pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c-346-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c:347:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c-348-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1361=static void intel_eth_pci_remove(struct pci_dev pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1365-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1366:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1367-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=578=static void loongson_dwmac_remove(struct pci_dev pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-584-\tld = priv-\u003eplat-\u003ebsp_priv;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:585:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-586-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c=362=static void motorcomm_remove(struct pci_dev pdev)\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-363-{\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c:364:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-365-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c=595=static void stm32_dwmac_remove(struct platform_device pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c-600-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c:601:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c-602-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h=412=int stmmac_suspend(struct device dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h:413:void stmmac_dvr_remove(struct device dev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h-414-int stmmac_dvr_probe(struct device device,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=8162=EXPORT_SYMBOL_GPL(stmmac_dvr_probe);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8164-/*\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8165: stmmac_dvr_remove\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8166- * @dev: device pointer\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8169- /\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8170:void stmmac_dvr_remove(struct device dev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8171-{\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8203-}\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8204:EXPORT_SYMBOL_GPL(stmmac_dvr_remove);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8205-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=192=static void stmmac_pci_remove(struct pci_dev pdev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-193-{\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:194:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-195-}\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c=897=void stmmac_pltfr_remove(struct platform_device pdev)\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-898-{\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:899:\tstmmac_dvr_remove(\u0026pdev-\u003edev);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-900-}\n" }
55/2	2026/08/14 06:38	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 46342 output: 23 thoughts: 773 Thoughts: My Analysis of the STMMAC Driver Changes Okay, so I've been looking at this patch and trying to figure out the best approach for fuzzing the changes it introduces to the STMMAC driver. My initial thought was that `stmmac_dvr_remove` would be a good symbol to focus on, and while it still is, I think I've identified some even better targets. Let's list them all out, starting with the original suggestion: * `stmmac_dvr_probe` * `stmmac_dvr_remove` * `stmmac_suspend` * `stmmac_resume` * `stmmac_xdp_open` * `stmmac_xdp_release` * `stmmac_reinit_queues` * `stmmac_reinit_ringparam` I initially thought `stmmac_dvr_probe` was the key. But, no. I was mistaken about its role in calling `stmmac_hw_setup`. My understanding is that `stmmac_dvr_probe` registers the net device, whereas `stmmac_open` calls `stmmac_hw_setup`. `stmmac_open` is static, so syzkaller should be able to reach it via `ndo_open`. I'm also considering `stmmac_reinit_queues` and `stmmac_reinit_ringparam`, since they call `stmmac_open` as well. However, the more I think about it, the more I'm leaning towards `stmmac_xdp_open` as a prime target. It calls `stmmac_start_all_dma` and `stmmac_mac_set`. That looks like a pretty juicy entry point. Now, a quick check on `stmmac_datapath_teardown` and its reachability via `stmmac_suspend`: Yes, `stmmac_suspend` does call `stmmac_datapath_teardown(priv)` if `priv->wolopts` is false. And of course, `stmmac_resume` calls `stmmac_hw_setup(ndev)`. So, `stmmac_suspend` and `stmmac_resume` are definitely worth including on the list. Here's my distilled summary: * WorthFuzzing: True * Reasoning: This patch makes significant changes to the STMMAC driver, specifically regarding the order of operations during datapath teardown and setup for all STMMAC devices, modifying the DMA stop/MAC disable and MAC enable/DMA start sequences. These functional changes in core logic are reachable through PCI emulation. * FocusSymbols: * `stmmac_dvr_remove` * `stmmac_suspend` * `stmmac_resume` * `stmmac_xdp_open` * `stmmac_xdp_release` * `stmmac_reinit_queues` * `stmmac_reinit_ringparam` * EnableConfigs: * `STMMAC_ETH` * `STMMAC_PCI` I've made sure to check the dependencies. `STMMAC_ETH` depends on `HAS_IOMEM` and `HAS_DMA` – standard stuff. `STMMAC_PCI` depends on `PCI` and `COMMON_CLK`. I don't think we need anything special for XDP beyond `BPF_SYSCALL`, which is also fairly standard. Therefore, `STMMAC_ETH` and `STMMAC_PCI` should be sufficient for reproducing this issue. One final point – the patch also touches `dwxgmac2_dma.c`. I need to confirm whether `dwxgmac2_dma.c`, which implements `dwxgmac210_dma_ops`, gets compiled when `STMMAC_ETH` is enabled. It is important to confirm that the changes in that file are covered by the current configuration.
56/2	2026/08/14 06:38	tool	grepper	0m Args: { "Expression": "dwxgmac2_dma.o" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/Makefile=3=stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o\t\\\n--\ndrivers/net/ethernet/stmicro/stmmac/Makefile-7-\t dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \\\ndrivers/net/ethernet/stmicro/stmmac/Makefile:8:\t stmmac_tc.o dwxgmac2_core.o dwxgmac2_dma.o dwxgmac2_descs.o \\\ndrivers/net/ethernet/stmicro/stmmac/Makefile-9-\t stmmac_xdp.o stmmac_est.o stmmac_fpe.o stmmac_vlan.o \\\n" }
57/2	2026/08/14 06:38	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48305 output: 178 thoughts: 157 Thoughts: My Assessment of the `stmmac` Changes Okay, so I've confirmed that these changes are indeed within the `stmmac-objs` scope, as expected. Let's delve into the core of these modifications. I'm focusing on the key symbols affected: `stmmac_dvr_remove`, `stmmac_suspend`, `stmmac_resume`, `stmmac_xdp_open`, `stmmac_xdp_release`, `stmmac_reinit_queues`, and `stmmac_reinit_ringparam`. Looking at this list, the impact is immediately apparent. These symbols encapsulate the critical areas where the driver's operational flow has been altered. Specifically, this patch changes the sequencing of MAC enable/disable actions relative to the DMA start/stop operations. This is a functional alteration; it's changing how the core driver handles the fundamental hardware interactions across all stmmac devices. It's not just a refactoring or optimization, it's a fundamental shift in the driver's control logic. Alright, with this understanding confirmed, I'm comfortable calling `set-results`.
58/2	2026/08/14 06:38	tool	set-results	0m Args: { "EnableConfigs": [ "STMMAC_ETH", "STMMAC_PCI" ], "FocusSymbols": [ "stmmac_dvr_remove", "stmmac_suspend", "stmmac_resume", "stmmac_xdp_open", "stmmac_xdp_release", "stmmac_reinit_queues", "stmmac_reinit_ringparam" ], "Reasoning": "The patch introduces a new ordered datapath teardown sequence for all stmmac devices, changing the order of DMA stop and MAC disable operations. It also swaps the order of MAC enable and DMA start in the setup paths. These are functional changes to the core driver logic reachable via PCI emulation.", "WorthFuzzing": true } Results: { "EnableConfigs": [ "STMMAC_ETH", "STMMAC_PCI" ], "FocusSymbols": [ "stmmac_dvr_remove", "stmmac_suspend", "stmmac_resume", "stmmac_xdp_open", "stmmac_xdp_release", "stmmac_reinit_queues", "stmmac_reinit_ringparam" ], "Reasoning": "The patch introduces a new ordered datapath teardown sequence for all stmmac devices, changing the order of DMA stop and MAC disable operations. It also swaps the order of MAC enable and DMA start in the setup paths. These are functional changes to the core driver logic reachable via PCI emulation.", "WorthFuzzing": true }
59/1	2026/08/14 06:38	action	If	0m Args: { "WorthFuzzing": true } Results: null
60/2	2026/08/14 06:38	agent	kmsan-evaluator	0m Model: best-expensive Args: null Results: { "KMSANReasoning": "The patch modifies the hardware initialization and teardown sequences in the stmmac driver, introducing an ordered datapath teardown to properly stop DMA and MAC operations. It adds functions to poll hardware registers for specific states (e.g., DMA stopped, MTL queues drained) using `readl_poll_timeout`. These changes are purely related to hardware control flow and do not introduce any new data structures, buffer allocations, or data copies to user space. There is no risk of uninitialized memory being exposed or used in control flow. Standard KASAN and other bug detectors are sufficient to catch any potential memory corruption or use-after-free bugs that might arise from driver teardown issues.", "NeedsKMSAN": false } Instruction: You are an expert Linux kernel security engineer specializing in kernel memory error detectors (KASAN and KMSAN). Your job is to review the provided patch series and determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer) fuzzing session in addition to standard KASAN fuzzing. CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN: - Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable a comprehensive suite of debugging tools and sanitizers, including KASAN (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks. - KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap, or page allocations) and kernel-to-user memory info-leaks. Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN, LOCKDEP, OR OTHER STANDARD BUG DETECTORS. A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks that are detected ONLY by KMSAN. Look holistically at the patch series and surrounding code. Even if no direct uninitialized field accesses or new buffer allocations are added in the diff itself, a patch may alter control flow, bounds checking, or data length calculations in ways that change how the rest of the code operates on existing buffers (e.g. allowing uninitialized stack/heap memory to be read, copied to user space, or used in control flow). Do not hesitate to use your code access tools to inspect the surrounding code, called functions, and callers. Set NeedsKMSAN=true ONLY IF the patch introduces or modifies: 1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb attributes, ioctl output arguments, socket options, or BPF buffers) where fields or structure padding might not be fully initialized/zeroed. 2. Conditional logic or branching that depends on potentially uninitialized variables or struct fields. 3. Allocation or initialization of complex data structures where uninitialized fields could be read later in reachable code paths. 4. Bounds checks, lengths, or logic in a way that allows surrounding code to access uninitialized bytes of existing buffers. Set NeedsKMSAN=false IF: - The code changes primarily risk out-of-bounds access, array overflows, NULL pointer dereferences, locking deadlocks, or use-after-free bugs (these are already caught by KASAN, LOCKDEP, or standard bug detectors). - All stack/heap structures touched or introduced by the patch are fully zeroed or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied. - The patch does not introduce any risk of uninitialized memory usage or info-leaks. Use your code access tools to inspect the surrounding code if necessary, then provide detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch. 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. Prompt: For your convenience, here is the diff of the changes: commit a08ff34cb2cd2d29c1e2615dd14480ccb2d870fb Author: syz-cluster <triage@syzkaller.com> Date: Fri Aug 14 06:35:32 2026 +0000 syz-cluster: applied patch under review diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h index f8ab347f7b5b9..50f9ccd4a9c46 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h @@ -291,6 +291,10 @@ #define XGMAC_TTC GENMASK(6, 4) #define XGMAC_TXQEN GENMASK(3, 2) #define XGMAC_TSF BIT(1) +#define XGMAC_MTL_TXQ_DEBUG(x) (0x00001108 + (0x80 * (x))) +#define XGMAC_TXQSTS BIT(4) +#define XGMAC_TRCSTS GENMASK(2, 1) +#define XGMAC_TRCSTS_READ 0x1 #define XGMAC_MTL_TCx_ETS_CONTROL(x) (0x00001110 + (0x80 * (x))) #define XGMAC_MTL_TCx_QUANTUM_WEIGHT(x) (0x00001118 + (0x80 * (x))) #define XGMAC_MTL_TCx_SENDSLOPE(x) (0x0000111c + (0x80 * (x))) @@ -306,6 +310,9 @@ #define XGMAC_EHFC BIT(7) #define XGMAC_RSF BIT(5) #define XGMAC_RTC GENMASK(1, 0) +#define XGMAC_MTL_RXQ_DEBUG(x) (0x00001148 + (0x80 * (x))) +#define XGMAC_PRXQ GENMASK(29, 16) +#define XGMAC_RXQSTS GENMASK(5, 4) #define XGMAC_MTL_RXQ_FLOW_CONTROL(x) (0x00001150 + (0x80 * (x))) #define XGMAC_RFD GENMASK(31, 17) #define XGMAC_RFA GENMASK(15, 1) @@ -391,6 +398,7 @@ #define XGMAC_NIS BIT(15) #define XGMAC_AIS BIT(14) #define XGMAC_FBE BIT(12) +#define XGMAC_RPS BIT(8) #define XGMAC_RBU BIT(7) #define XGMAC_RI BIT(6) #define XGMAC_TBU BIT(2) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c index ff83858ebc1f3..ba4f535fb9eb4 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c @@ -4,6 +4,7 @@ * stmmac XGMAC support. / +#include <linux/bitfield.h> #include <linux/iopoll.h> #include "stmmac.h" #include "dwxgmac2.h" @@ -261,13 +262,12 @@ static void dwxgmac2_dma_start_tx(struct stmmac_priv priv, { u32 value; + /* TPS is latched once set, so clear it on every Tx DMA start. / + writel(XGMAC_TPS, ioaddr + XGMAC_DMA_CH_STATUS(chan)); + value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); value \|= XGMAC_TXST; writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); - - value = readl(ioaddr + XGMAC_TX_CONFIG); - value \|= XGMAC_CONFIG_TE; - writel(value, ioaddr + XGMAC_TX_CONFIG); } static void dwxgmac2_dma_stop_tx(struct stmmac_priv priv, void __iomem ioaddr, @@ -278,10 +278,6 @@ static void dwxgmac2_dma_stop_tx(struct stmmac_priv priv, void __iomem ioaddr, value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); value &= ~XGMAC_TXST; writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan)); - - value = readl(ioaddr + XGMAC_TX_CONFIG); - value &= ~XGMAC_CONFIG_TE; - writel(value, ioaddr + XGMAC_TX_CONFIG); } static void dwxgmac2_dma_start_rx(struct stmmac_priv priv, @@ -289,13 +285,12 @@ static void dwxgmac2_dma_start_rx(struct stmmac_priv priv, { u32 value; + / RPS is latched once set, so clear it on every Rx DMA start. / + writel(XGMAC_RPS, ioaddr + XGMAC_DMA_CH_STATUS(chan)); + value = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan)); value \|= XGMAC_RXST; writel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan)); - - value = readl(ioaddr + XGMAC_RX_CONFIG); - value \|= XGMAC_CONFIG_RE; - writel(value, ioaddr + XGMAC_RX_CONFIG); } static void dwxgmac2_dma_stop_rx(struct stmmac_priv priv, void __iomem ioaddr, @@ -592,6 +587,77 @@ static int dwxgmac2_enable_tbs(struct stmmac_priv priv, void __iomem ioaddr, return 0; } +static int dwxgmac2_tx_dma_stopped(struct stmmac_priv priv, + void __iomem ioaddr, u32 chan) +{ + u32 value; + int ret; + + ret = readl_poll_timeout(ioaddr + XGMAC_DMA_CH_STATUS(chan), value, + value & XGMAC_TPS, 100, 10000); + if (ret) + netdev_warn(priv->dev, "Tx DMA channel %u stop timeout\n", + chan); + + return ret; +} + +static int dwxgmac2_tx_mtl_drain(struct stmmac_priv priv, + void __iomem ioaddr, u32 queue) +{ + u32 value; + int ret; + + / Wait until the queue is empty and its read controller is no longer + * pulling a frame out towards the MAC. + / + ret = readl_poll_timeout(ioaddr + XGMAC_MTL_TXQ_DEBUG(queue), value, + !(value & XGMAC_TXQSTS) && + FIELD_GET(XGMAC_TRCSTS, value) != + XGMAC_TRCSTS_READ, + 100, 10000); + if (ret) + netdev_warn(priv->dev, "MTL Tx queue %u drain timeout\n", + queue); + + return ret; +} + +static int dwxgmac2_rx_mtl_drain(struct stmmac_priv priv, + void __iomem ioaddr, u32 queue) +{ + u32 value; + int ret; + + / Wait until no packet is left in the queue and the queue reports + * itself empty. + / + ret = readl_poll_timeout(ioaddr + XGMAC_MTL_RXQ_DEBUG(queue), value, + !FIELD_GET(XGMAC_PRXQ, value) && + !FIELD_GET(XGMAC_RXQSTS, value), + 100, 10000); + if (ret) + netdev_warn(priv->dev, "MTL Rx queue %u drain timeout\n", + queue); + + return ret; +} + +static int dwxgmac2_rx_dma_stopped(struct stmmac_priv priv, + void __iomem ioaddr, u32 chan) +{ + u32 value; + int ret; + + ret = readl_poll_timeout(ioaddr + XGMAC_DMA_CH_STATUS(chan), value, + value & XGMAC_RPS, 100, 10000); + if (ret) + netdev_warn(priv->dev, "Rx DMA channel %u stop timeout\n", + chan); + + return ret; +} + const struct stmmac_dma_ops dwxgmac210_dma_ops = { .reset = dwxgmac2_dma_reset, .init = dwxgmac2_dma_init, @@ -620,4 +686,8 @@ const struct stmmac_dma_ops dwxgmac210_dma_ops = { .set_bfsize = dwxgmac2_set_bfsize, .enable_sph = dwxgmac2_enable_sph, .enable_tbs = dwxgmac2_enable_tbs, + .tx_dma_stopped = dwxgmac2_tx_dma_stopped, + .tx_mtl_drain = dwxgmac2_tx_mtl_drain, + .rx_mtl_drain = dwxgmac2_rx_mtl_drain, + .rx_dma_stopped = dwxgmac2_rx_dma_stopped, }; diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h index 04dafec021b4f..86f4aa88961c7 100644 --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h @@ -231,6 +231,15 @@ struct stmmac_dma_ops { bool en, u32 chan); int (enable_tbs)(struct stmmac_priv priv, void __iomem ioaddr, bool en, u32 chan); + /* Ordered datapath teardown / + int (tx_dma_stopped)(struct stmmac_priv priv, void __iomem ioaddr, + u32 chan); + int (tx_mtl_drain)(struct stmmac_priv priv, void __iomem ioaddr, + u32 queue); + int (rx_mtl_drain)(struct stmmac_priv priv, void __iomem ioaddr, + u32 queue); + int (rx_dma_stopped)(struct stmmac_priv priv, void __iomem ioaddr, + u32 chan); }; #define stmmac_dma_init(__priv, __args...) \ @@ -293,6 +302,14 @@ struct stmmac_dma_ops { stmmac_do_void_callback(__priv, dma, enable_sph, __priv, __args) #define stmmac_enable_tbs(__priv, __args...) \ stmmac_do_callback(__priv, dma, enable_tbs, __priv, __args) +#define stmmac_tx_dma_stopped(__priv, __args...) \ + stmmac_do_callback(__priv, dma, tx_dma_stopped, __priv, __args) +#define stmmac_tx_mtl_drain(__priv, __args...) \ + stmmac_do_callback(__priv, dma, tx_mtl_drain, __priv, __args) +#define stmmac_rx_mtl_drain(__priv, __args...) \ + stmmac_do_callback(__priv, dma, rx_mtl_drain, __priv, __args) +#define stmmac_rx_dma_stopped(__priv, __args...) \ + stmmac_do_callback(__priv, dma, rx_dma_stopped, __priv, __args) struct mac_device_info; struct net_device; diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index b2b7d0242dd3c..9c3a8f122b94f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2560,6 +2560,52 @@ static void stmmac_stop_all_dma(struct stmmac_priv priv) stmmac_deinit_chan(priv, priv->ioaddr, chan); } +/** + * stmmac_datapath_teardown - ordered datapath teardown as per IP specification + * @priv: driver private structure + * Description: + * When teardown ops are available, follow the databook ordered teardown + * sequence. + * Follows the legacy stop + MAC disable for variants without the feature. + / +static void stmmac_datapath_teardown(struct stmmac_priv priv) +{ + u32 rx_channels_count = priv->plat->rx_queues_to_use; + u32 tx_channels_count = priv->plat->tx_queues_to_use; + u32 chan; + + /* Stop all TX DMA channels / + for (chan = 0; chan < tx_channels_count; chan++) + stmmac_stop_tx_dma(priv, chan); + + / Wait for every TX DMA channel to report itself stopped / + if (priv->hw->dma->tx_dma_stopped) + for (chan = 0; chan < tx_channels_count; chan++) + stmmac_tx_dma_stopped(priv, priv->ioaddr, chan); + + / Wait for the MTL TX queues to finish pushing into the MAC / + if (priv->hw->dma->tx_mtl_drain) + for (chan = 0; chan < tx_channels_count; chan++) + stmmac_tx_mtl_drain(priv, priv->ioaddr, chan); + + / Disable the MAC TX and RX / + stmmac_mac_set(priv, priv->ioaddr, false); + + / Wait for the MTL RX queues to drain into the RX DMA / + if (priv->hw->dma->rx_mtl_drain) + for (chan = 0; chan < rx_channels_count; chan++) + stmmac_rx_mtl_drain(priv, priv->ioaddr, chan); + + / Stop all RX DMA channels / + for (chan = 0; chan < rx_channels_count; chan++) + stmmac_stop_rx_dma(priv, chan); + + / Wait for every RX DMA channel to report itself stopped / + if (priv->hw->dma->rx_dma_stopped) + for (chan = 0; chan < rx_channels_count; chan++) + stmmac_rx_dma_stopped(priv, priv->ioaddr, chan); +} + /* * stmmac_dma_operation_mode - HW DMA operation mode * @priv: driver private structure @@ -3685,9 +3731,6 @@ static int stmmac_hw_setup(struct net_device dev) priv->hw->rx_csum = 0; } - / Enable the MAC Rx/Tx / - stmmac_mac_set(priv, priv->ioaddr, true); - / Set the HW DMA mode and the COE / stmmac_dma_operation_mode(priv); @@ -3743,6 +3786,9 @@ static int stmmac_hw_setup(struct net_device dev) /* Start the ball rolling... / stmmac_start_all_dma(priv); + / Enable the MAC Rx/Tx / + stmmac_mac_set(priv, priv->ioaddr, true); + phylink_rx_clk_stop_block(priv->phylink); stmmac_set_hw_vlan_mode(priv, priv->hw); phylink_rx_clk_stop_unblock(priv->phylink); @@ -4240,9 +4286,6 @@ static void __stmmac_release(struct net_device dev) struct stmmac_priv priv = netdev_priv(dev); u8 chan; - / Stop and disconnect the PHY / - phylink_stop(priv->phylink); - stmmac_disable_all_queues(priv); for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++) @@ -4253,8 +4296,11 @@ static void __stmmac_release(struct net_device dev) /* Free the IRQ lines / stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0); - / Stop TX/RX DMA and clear the descriptors / - stmmac_stop_all_dma(priv); + / Has to run before mac_link_down() disables the MAC. / + stmmac_datapath_teardown(priv); + + / Stop and disconnect the PHY / + phylink_stop(priv->phylink); / Release and free the Rx/Tx resources / free_dma_desc_resources(priv, &priv->dma_conf); @@ -7104,15 +7150,12 @@ void stmmac_xdp_release(struct net_device dev) /* Free the IRQ lines / stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0); - / Stop TX/RX DMA channels / - stmmac_stop_all_dma(priv); + / Stop the MAC and the TX/RX DMA channels / + stmmac_datapath_teardown(priv); / Release and free the Rx/Tx resources / free_dma_desc_resources(priv, &priv->dma_conf); - / Disable the MAC Rx/Tx / - stmmac_mac_set(priv, priv->ioaddr, false); - / set trans_start so we don't get spurious * watchdogs during reset / @@ -7184,12 +7227,12 @@ int stmmac_xdp_open(struct net_device dev) hrtimer_setup(&tx_q->txtimer, stmmac_tx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); } - /* Enable the MAC Rx/Tx / - stmmac_mac_set(priv, priv->ioaddr, true); - / Start Rx & Tx DMA Channels / stmmac_start_all_dma(priv); + / Enable the MAC Rx/Tx / + stmmac_mac_set(priv, priv->ioaddr, true); + ret = stmmac_request_irq(dev); if (ret) goto irq_error; @@ -8190,17 +8233,15 @@ int stmmac_suspend(struct device dev) timer_delete_sync(&priv->eee_ctrl_timer); } - /* Stop TX/RX DMA / - stmmac_stop_all_dma(priv); - - stmmac_legacy_serdes_power_down(priv); - / Enable Power down mode by programming the PMT regs */ if (priv->wolopts) { + stmmac_stop_all_dma(priv); + stmmac_legacy_serdes_power_down(priv); stmmac_pmt(priv, priv->hw, priv->wolopts); priv->irq_wake = 1; } else { - stmmac_mac_set(priv, priv->ioaddr, false); + stmmac_datapath_teardown(priv); + stmmac_legacy_serdes_power_down(priv); pinctrl_pm_select_sleep_state(priv->device); }
61/3	2026/08/14 06:38	llm	kmsan-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7381 output: 165 thoughts: 367 Thoughts: My Assessment of the STMMAC Driver Patch Alright, let's break this down. This patch is focused solely on the internal workings of the `stmmac` driver, specifically the `dwxgmac2` variant. It's about ensuring a proper, ordered shutdown sequence for the datapath. I see that they've added these new polling functions: `dwxgmac2_tx_dma_stopped`, `dwxgmac2_tx_mtl_drain`, `dwxgmac2_rx_mtl_drain`, and `dwxgmac2_rx_dma_stopped`. These will poll hardware registers to check the state of the system. The core of the change lies in the `stmmac_datapath_teardown` function, which orchestrates the controlled shutdown: stopping TX DMA, waiting for completion, draining the MTL TX, disabling MAC TX/RX, draining the MTL RX, stopping RX DMA, and waiting again. It is also modifying the order of enabling and disabling MAC and DMA in several key functions. Nothing revolutionary here, it seems. Given my understanding of networking stacks, it's pretty clear this is purely about hardware control flow, which is where things get interesting. No new data structures are being introduced that are sent to user space, no buffer allocations, no memory-related issues. The functions simply call `readl_poll_timeout`, with `value` initialized properly within. From my expertise, that means there are no concerns about info-leaks. I've carefully considered the potential for uninitialized memory issues, and I am confident that there are none based on the patch description and my analysis. Given this, I can confidently set `NeedsKMSAN=false`. This one's clean.
62/3	2026/08/14 06:38	tool	set-results	0m Args: { "KMSANReasoning": "The patch modifies the hardware initialization and teardown sequences in the stmmac driver, introducing an ordered datapath teardown to properly stop DMA and MAC operations. It adds functions to poll hardware registers for specific states (e.g., DMA stopped, MTL queues drained) using `readl_poll_timeout`. These changes are purely related to hardware control flow and do not introduce any new data structures, buffer allocations, or data copies to user space. There is no risk of uninitialized memory being exposed or used in control flow. Standard KASAN and other bug detectors are sufficient to catch any potential memory corruption or use-after-free bugs that might arise from driver teardown issues.", "NeedsKMSAN": false } Results: { "KMSANReasoning": "The patch modifies the hardware initialization and teardown sequences in the stmmac driver, introducing an ordered datapath teardown to properly stop DMA and MAC operations. It adds functions to poll hardware registers for specific states (e.g., DMA stopped, MTL queues drained) using `readl_poll_timeout`. These changes are purely related to hardware control flow and do not introduce any new data structures, buffer allocations, or data copies to user space. There is no risk of uninitialized memory being exposed or used in control flow. Standard KASAN and other bug detectors are sufficient to catch any potential memory corruption or use-after-free bugs that might arise from driver teardown issues.", "NeedsKMSAN": false }

LLM Calls Summary:
Total Calls	Total Tokens	Avg Tokens	Total Duration (Seconds)	Avg Duration (Seconds)

Tool Calls Summary:
Total Calls	Total Duration (Seconds)	Avg Duration (Seconds)