AI Trajectory

null

{
  "EnableConfigs": [
    "STMMAC_ETH",
    "STMMAC_PCI"
  ],
  "FocusSymbols": [
    "stmmac_select_queue"
  ],
  "KMSANReasoning": "The patch modifies the logic for selecting a transmission queue for network packets (sk_buff) in the stmmac driver. It checks the `gso_type` of the packet against `priv-\u003egso_enabled_types` and verifies if the selected queue permits TSO via `stmmac_tso_channel_permitted()`. These changes only affect control flow and queue selection based on already initialized fields in the `sk_buff` and the driver's private data structure. There are no new allocations, no structures copied to user space, and no risk of exposing uninitialized memory. Any potential bugs introduced by this patch would be related to incorrect queue selection or out-of-bounds queue indices, which are effectively caught by standard KASAN and other bug detectors. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the queue selection logic for GSO frames in the STMicroelectronics DWMAC driver. The driver can be probed via PCI and tested in virtualized environments.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 019f53ec44f68222b12021684ca06a008c14dd1c\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Aug 7 15:34:19 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\nindex b2b7d0242dd3c..99fc7313f247e 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\n+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\n@@ -6445,19 +6445,18 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,\n static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,\n \t\t\t       struct net_device *sb_dev)\n {\n-\tint gso = skb_shinfo(skb)-\u003egso_type;\n+\tu32 queue = netdev_pick_tx(dev, skb, NULL) % dev-\u003ereal_num_tx_queues;\n+\tstruct stmmac_priv *priv = netdev_priv(dev);\n \n-\tif (gso \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6 | SKB_GSO_UDP_L4)) {\n-\t\t/*\n-\t\t * There is no way to determine the number of TSO/USO\n-\t\t * capable Queues. Let's use always the Queue 0\n-\t\t * because if TSO/USO is supported then at least this\n-\t\t * one will be capable.\n+\tif ((skb_shinfo(skb)-\u003egso_type \u0026 priv-\u003egso_enabled_types) \u0026\u0026\n+\t    !stmmac_tso_channel_permitted(priv, queue)) {\n+\t\t/* GSO frames need HW TSO/USO, which cannot run on TBS queues.\n+\t\t * Fall back to the queue reserved for TSO (queue 0).\n \t\t */\n \t\treturn 0;\n \t}\n \n-\treturn netdev_pick_tx(dev, skb, NULL) % dev-\u003ereal_num_tx_queues;\n+\treturn queue;\n }\n \n static int stmmac_set_mac_address(struct net_device *ndev, void *addr)\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "STMMAC_ETH",
    "STMMAC_PCI"
  ],
  "FocusSymbols": [
    "stmmac_select_queue"
  ],
  "Reasoning": "The patch modifies the queue selection logic for GSO frames in the STMicroelectronics DWMAC driver. The driver can be probed via PCI and tested in virtualized environments.",
  "WorthFuzzing": true
}

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

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

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

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

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


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

For your convenience, here is the diff of the changes:
commit 019f53ec44f68222b12021684ca06a008c14dd1c
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Aug 7 15:34:19 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b2b7d0242dd3c..99fc7313f247e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6445,19 +6445,18 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,
 static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,
 			       struct net_device *sb_dev)
 {
-	int gso = skb_shinfo(skb)->gso_type;
+	u32 queue = netdev_pick_tx(dev, skb, NULL) % dev->real_num_tx_queues;
+	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if (gso & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6 | SKB_GSO_UDP_L4)) {
-		/*
-		 * There is no way to determine the number of TSO/USO
-		 * capable Queues. Let's use always the Queue 0
-		 * because if TSO/USO is supported then at least this
-		 * one will be capable.
+	if ((skb_shinfo(skb)->gso_type & priv->gso_enabled_types) &&
+	    !stmmac_tso_channel_permitted(priv, queue)) {
+		/* GSO frames need HW TSO/USO, which cannot run on TBS queues.
+		 * Fall back to the queue reserved for TSO (queue 0).
 		 */
 		return 0;
 	}
 
-	return netdev_pick_tx(dev, skb, NULL) % dev->real_num_tx_queues;
+	return queue;
 }
 
 static int stmmac_set_mac_address(struct net_device *ndev, void *addr)

gemini-3.1-pro-preview

null

null

							input: 2356
							output: 20
							thoughts: 433
						

**Analyzing the Impact of a `stmmac` Queue Selection Patch**

Okay, so there's a patch floating around that's tweaking how `stmmac_select_queue` works, specifically for GSO frames in `drivers/net/ethernet/stmicro/stmmac/stmmac_main.c`. The core change seems to be around queue selection; instead of the default of returning queue 0 for GSO frames, it's attempting to select a queue. And only if the chosen queue isn't suitable for TSO does it fallback to queue 0.

Now, I need to understand the implications of this.  A critical question here is, can I readily test this change in a virtualized environment?  `stmmac`, as I recall, is the STMicroelectronics Ethernet driver for 10/100/1000/EQOS. Is it emulated by QEMU? I don't think QEMU *natively* emulates `stmmac`. I have to dig a bit. Perhaps it's present in an emulated ARM board within QEMU. Or perhaps it's not even testable there.

Hmm, let's see what's in QEMU's network device list: `hw/net/imx_fec.c`, `hw/net/cadence_gem.c`, `hw/net/allwinner-sun8i-emac.c`, `hw/net/ftgmac100.c`, `hw/net/npcm7xx_emc.c`, `hw/net/smc91c111.c`, `hw/net/lan9118.c`, `hw/net/xgmac.c` (Highbank/Midway). Wait, could `xgmac` be `stmmac` in disguise?  No, no, that's not right. `xgmac` seems to be either Calxeda or STMicroelectronics's DWMAC.

Right, so to continue this assessment, let's check its device binding: is `stmmac` a PCI device or a platform device? Aha! It has PCI bindings! That's good news; it improves the chances of testing. I'll need to examine `drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c`.

{
  "Expression": "stmmac_pci"
}

{
  "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"
}

gemini-3.1-pro-preview

null

null

							input: 10683
							output: 17
							thoughts: 499
						

**Analyzing the Testability of `stmmac` in Virtualized Environments**

Okay, so I'm trying to figure out if this `stmmac` driver is actually testable in a QEMU environment, given the constraints. My initial thought was that since the driver has PCI bindings (`stmmac_pci.c`), it *should* be probeable if a corresponding PCI device is emulated, or if I use a virtual PCI device. But then I paused - does QEMU even *emulate* STMMAC over PCI? I need to check.

Then I recalled that syzkaller often tests network drivers. Perhaps syzkaller utilizes `vnet` or `dummy` interfaces, or maybe even has some coverage without a direct PCI device. But then I remember that syzkaller can test it if it's a platform device on ARM, or if there's a PCI device.

But then the prompt specifically mentions code paths that are impossible to reach in environments like QEMU. It cites examples like vendor-specific PCIe switch or SmartNIC drivers, the kinds of things that require dedicated hardware. Could `stmmac` fall into that category?

I need to get to the root of how `stmmac` is used. I know it's used in numerous ARM SoCs from Rockchip, Allwinner, Amlogic, NXP, and others. I know QEMU *does* emulate some of these SoCs – I've seen `allwinner-sun8i-emac` (mapped to `sun8i-emac`, not `stmmac`). I'm looking for where `stmmac` gets used in QEMU. Let me look at the QEMU source.

Okay, I see `hw/net/allwinner-sun8i-emac.c`, that's `sun8i-emac`. Then there's `hw/net/cadence_gem.c`, that's for the `macb` driver. And `hw/net/imx_fec.c`, that's `fec`. `hw/net/npcm7xx_emc.c` is for `npcm7xx_emc`, and `hw/net/xgmac.c` is obviously `xgmac`. I am wondering if `stmmac` can even be used in QEMU at all?

Wait, I think I remember now. `stmmac` is the Synopsys DesignWare MAC (DWMAC). So that means QEMU *should* have an emulation of this. Let me see... yes! QEMU has `hw/net/designware.c`. Okay, now I just need to verify that this is what I'm looking for.

{
  "Expression": "DWMAC"
}

{
  "Output": "\nFull output is too long, showing 500 out of 1198 lines.\nUse more precise expression if possible.\n\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml-6-\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml:7:title: Altera SOCFPGA SoC DWMAC controller\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml-8-\n--\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml=12=description:\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml-13-  This binding describes the Altera SOCFPGA SoC implementation of the\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml:14:  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, Agilex5 and Agilex7\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml-15-  families of chips.\n--\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml=31=properties:\n--\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml-113-    description:\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml:114:      Should be the phandle to the emac splitter soft IP node if DWMAC\nDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml-115-      controller is connected an emac splitter.\n--\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml=6=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml-7-\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml:8:title: Amlogic Meson DWMAC Ethernet controller\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml-9-\n--\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml=130=properties:\n--\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml-149-      - description:\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml:150:          The first register range should be the one of the DWMAC controller\nDocumentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml-151-      - description:\n--\nDocumentation/devicetree/bindings/net/intel,dwmac-plat.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/intel,dwmac-plat.yaml-6-\nDocumentation/devicetree/bindings/net/intel,dwmac-plat.yaml:7:title: Intel DWMAC glue layer\nDocumentation/devicetree/bindings/net/intel,dwmac-plat.yaml-8-\n--\nDocumentation/devicetree/bindings/net/ipq806x-dwmac.txt:1:* IPQ806x DWMAC Ethernet controller\nDocumentation/devicetree/bindings/net/ipq806x-dwmac.txt-2-\n--\nDocumentation/devicetree/bindings/net/mediatek-dwmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/mediatek-dwmac.yaml-6-\nDocumentation/devicetree/bindings/net/mediatek-dwmac.yaml:7:title: MediaTek DWMAC glue layer controller\nDocumentation/devicetree/bindings/net/mediatek-dwmac.yaml-8-\n--\nDocumentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml-6-\nDocumentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml:7:title: Nuvoton DWMAC glue layer controller\nDocumentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml-8-\n--\nDocumentation/devicetree/bindings/net/nxp,dwmac-imx.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/nxp,dwmac-imx.yaml-6-\nDocumentation/devicetree/bindings/net/nxp,dwmac-imx.yaml:7:title: NXP i.MX8/9 DWMAC glue layer\nDocumentation/devicetree/bindings/net/nxp,dwmac-imx.yaml-8-\n--\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml=13=description:\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml-14-  This device is a Synopsys DWC IP, integrated on NXP S32G/R SoCs.\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml:15:  The SoC series S32G2xx and S32G3xx feature one DWMAC instance,\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml-16-  the SoC S32R45 has two instances. The devices can use RGMII/RMII/MII\n--\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml-18-  to the embedded SerDes for SGMII connectivity.\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml:19:  The DWMAC instances have connected all RX/TX queues interrupts,\nDocumentation/devicetree/bindings/net/nxp,s32-dwmac.yaml-20-  enabling load balancing of data traffic across all CPU cores.\n--\nDocumentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml-6-\nDocumentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml:7:title: Sophgo CV1800B DWMAC glue layer\nDocumentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml-8-\n--\nDocumentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml-6-\nDocumentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml:7:title: Sophgo SG2044 DWMAC glue layer\nDocumentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml-8-\n--\nDocumentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml-6-\nDocumentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml:7:title: Spacemit K3 DWMAC glue layer\nDocumentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml-8-\n--\nDocumentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml=6=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml-7-\nDocumentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml:8:title: StarFive JH7110 DWMAC glue layer\nDocumentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml-9-\n--\nDocumentation/devicetree/bindings/net/sti-dwmac.txt:1:STMicroelectronics SoC DWMAC glue layer controller\nDocumentation/devicetree/bindings/net/sti-dwmac.txt-2-\n--\nDocumentation/devicetree/bindings/net/stm32-dwmac.yaml=6=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/stm32-dwmac.yaml-7-\nDocumentation/devicetree/bindings/net/stm32-dwmac.yaml:8:title: STMicroelectronics STM32 / MCU DWMAC glue layer controller\nDocumentation/devicetree/bindings/net/stm32-dwmac.yaml-9-\n--\nDocumentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml=5=$schema: http://devicetree.org/meta-schemas/core.yaml#\nDocumentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml-6-\nDocumentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml:7:title: Toshiba Visconti DWMAC Ethernet controller\nDocumentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml-8-\n--\nDocumentation/networking/devlink/stmmac.rst=13=The ``stmmac`` driver implements the following driver-specific parameters.\n--\nDocumentation/networking/devlink/stmmac.rst-24-     - runtime\nDocumentation/networking/devlink/stmmac.rst:25:     - Enable the Coarse timestamping mode, as defined in the DWMAC TRM.\nDocumentation/networking/devlink/stmmac.rst-26-       A detailed explanation of this timestamping mode can be found in the\n--\nMAINTAINERS=3338=F:\tdrivers/pci/controller/dwc/pcie-nxp-s32g*\nMAINTAINERS-3339-\nMAINTAINERS:3340:ARM/NXP S32G/S32R DWMAC ETHERNET DRIVER\nMAINTAINERS-3341-M:\tJan Petrous \u003cjan.petrous@oss.nxp.com\u003e\n--\nMAINTAINERS=3604=F:\tdrivers/clk/socfpga/\nMAINTAINERS-3605-\nMAINTAINERS:3606:ARM/SOCFPGA DWMAC GLUE LAYER BINDINGS\nMAINTAINERS-3607-M:\tMatthew Gerlach \u003cmatthew.gerlach@altera.com\u003e\n--\nMAINTAINERS=3610=F:\tDocumentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml\nMAINTAINERS-3611-\nMAINTAINERS:3612:ARM/SOCFPGA DWMAC GLUE LAYER\nMAINTAINERS-3613-M:\tMaxime Chevallier \u003cmaxime.chevallier@bootlin.com\u003e\n--\nMAINTAINERS=18232=F:\tinclude/linux/most.h\nMAINTAINERS-18233-\nMAINTAINERS:18234:MOTORCOMM DWMAC GLUE DRIVER\nMAINTAINERS-18235-M:\tYao Zi \u003cme@ziyao.cc\u003e\n--\nMAINTAINERS=23043=F:\tdrivers/iio/adc/rzn1-adc.c\nMAINTAINERS-23044-\nMAINTAINERS:23045:RENESAS RZ/N1 DWMAC GLUE LAYER\nMAINTAINERS-23046-M:\tRomain Gantois \u003cromain.gantois@bootlin.com\u003e\n--\nMAINTAINERS=23065=F:\tdrivers/usb/gadget/udc/renesas_usbf.c\nMAINTAINERS-23066-\nMAINTAINERS:23067:RENESAS RZ/V2H(P) DWMAC GBETH GLUE LAYER DRIVER\nMAINTAINERS-23068-M:\tLad Prabhakar \u003cprabhakar.mahadev-lad.rj@bp.renesas.com\u003e\n--\nMAINTAINERS=25443=F:\tdrivers/media/dvb-frontends/sp2*\nMAINTAINERS-25444-\nMAINTAINERS:25445:SPACEMIT DWMAC GLUE LAYER\nMAINTAINERS-25446-M:\tInochi Amaoto \u003cinochiama@gmail.com\u003e\n--\nMAINTAINERS=25794=F:\tarch/riscv/boot/dts/starfive/\nMAINTAINERS-25795-\nMAINTAINERS:25796:STARFIVE DWMAC GLUE LAYER\nMAINTAINERS-25797-M:\tEmil Renner Berthing \u003ckernel@esmil.dk\u003e\n--\narch/arm/configs/multi_v7_defconfig=276=CONFIG_STMMAC_ETH=y\narch/arm/configs/multi_v7_defconfig:277:CONFIG_DWMAC_DWC_QOS_ETH=y\narch/arm/configs/multi_v7_defconfig-278-CONFIG_TI_CPSW=y\n--\narch/arm/configs/shmobile_defconfig=60=CONFIG_STMMAC_ETH=y\narch/arm/configs/shmobile_defconfig:61:# CONFIG_DWMAC_RENESAS_GBETH is not set\narch/arm/configs/shmobile_defconfig-62-CONFIG_MICREL_PHY=y\n--\narch/arm64/configs/defconfig=446=CONFIG_STMMAC_ETH=m\narch/arm64/configs/defconfig:447:CONFIG_DWMAC_MEDIATEK=m\narch/arm64/configs/defconfig:448:CONFIG_DWMAC_TEGRA=m\narch/arm64/configs/defconfig-449-# CONFIG_NET_VENDOR_SUN is not set\n--\narch/mips/configs/generic/board-ni169445.config=28=CONFIG_STMMAC_PLATFORM=y\narch/mips/configs/generic/board-ni169445.config:29:CONFIG_DWMAC_GENERIC=y\n--\narch/mips/configs/loongson1_defconfig=89=CONFIG_STMMAC_ETH=y\narch/mips/configs/loongson1_defconfig:90:# CONFIG_DWMAC_GENERIC is not set\narch/mips/configs/loongson1_defconfig-91-# CONFIG_NET_VENDOR_SYNOPSYS is not set\n--\narch/riscv/configs/defconfig=141=CONFIG_STMMAC_ETH=m\narch/riscv/configs/defconfig:142:CONFIG_DWMAC_THEAD=m\narch/riscv/configs/defconfig-143-CONFIG_MICREL_PHY=y\n--\ndrivers/gpu/drm/ci/arm.config=33=CONFIG_PHY_ROCKCHIP_DP=y\ndrivers/gpu/drm/ci/arm.config:34:CONFIG_DWMAC_ROCKCHIP=y\ndrivers/gpu/drm/ci/arm.config-35-\n--\ndrivers/gpu/drm/ci/arm64.config=35=CONFIG_PHY_ROCKCHIP_DP=y\ndrivers/gpu/drm/ci/arm64.config:36:CONFIG_DWMAC_ROCKCHIP=y\ndrivers/gpu/drm/ci/arm64.config-37-CONFIG_STMMAC_ETH=y\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig=42=if STMMAC_PLATFORM\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-43-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:44:config DWMAC_DWC_QOS_ETH\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-45-\ttristate \"Support for snps,dwc-qos-ethernet.txt DT binding.\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-51-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:52:config DWMAC_GENERIC\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:53:\ttristate \"Generic driver for DWMAC\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-54-\tdefault STMMAC_PLATFORM\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-55-\thelp\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:56:\t  Generic DWMAC driver for platforms that don't require any\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-57-\t  platform specific code to function or is using platform\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-59-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:60:config DWMAC_ANARION\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-61-\ttristate \"Adaptrum Anarion GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-68-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:69:config DWMAC_EIC7700\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-70-\ttristate \"Support for Eswin eic7700 ethernet driver\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-77-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:78:config DWMAC_INGENIC\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-79-\ttristate \"Ingenic MAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-89-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:90:config DWMAC_IPQ806X\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:91:\ttristate \"QCA IPQ806x DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-92-\tdefault ARCH_QCOM\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-95-\thelp\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:96:\t  Support for QCA IPQ806X DWMAC Ethernet.\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-97-\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-105-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:106:config DWMAC_LPC18XX\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:107:\ttristate \"NXP LPC18xx/43xx DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-108-\tdefault ARCH_LPC18XX\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-111-\thelp\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:112:\t  Support for NXP LPC18xx/43xx DWMAC Ethernet.\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-113-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:114:config DWMAC_MEDIATEK\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-115-\ttristate \"MediaTek MT27xx GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-121-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:122:config DWMAC_MESON\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-123-\ttristate \"Amlogic Meson dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-132-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:133:config DWMAC_NUVOTON\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-134-\ttristate \"Nuvoton MA35 dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-144-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:145:config DWMAC_QCOM_ETHQOS\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-146-\ttristate \"Qualcomm ETHQOS support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-154-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:155:config DWMAC_RENESAS_GBETH\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-156-\ttristate \"Renesas RZ/V2H(P) GBETH and RZ/T2H, RZ/N2H GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-167-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:168:config DWMAC_ROCKCHIP\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-169-\ttristate \"Rockchip dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-178-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:179:config DWMAC_RZN1\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-180-\ttristate \"Renesas RZ/N1 dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-190-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:191:config DWMAC_S32\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-192-\ttristate \"NXP S32G/S32R GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-202-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:203:config DWMAC_SOCFPGA\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-204-\ttristate \"SOCFPGA dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-217-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:218:config DWMAC_SOPHGO\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-219-\ttristate \"Sophgo dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-228-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:229:config DWMAC_SPACEMIT\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-230-\ttristate \"Spacemit dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-240-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:241:config DWMAC_STARFIVE\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-242-\ttristate \"StarFive dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-252-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:253:config DWMAC_STI\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-254-\ttristate \"STi GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-264-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:265:config DWMAC_STM32\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:266:\ttristate \"STM32 DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-267-\tdefault ARCH_STM32\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-276-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:277:config DWMAC_SUNXI\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-278-\ttristate \"Allwinner GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-287-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:288:config DWMAC_SUN8I\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-289-\ttristate \"Allwinner sun8i GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-299-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:300:config DWMAC_SUN55I\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-301-\ttristate \"Allwinner sun55i GMAC200 support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-311-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:312:config DWMAC_THEAD\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-313-\ttristate \"T-HEAD dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-321-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:322:config DWMAC_IMX8\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:323:\ttristate \"NXP IMX8 DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-324-\tdefault ARCH_MXC\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-333-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:334:config DWMAC_INTEL_PLAT\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-335-\ttristate \"Intel dwmac support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-343-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:344:config DWMAC_LOONGSON1\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-345-\ttristate \"Loongson1 GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-354-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:355:config DWMAC_TEGRA\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-356-\ttristate \"NVIDIA Tegra MGBE support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-363-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:364:config DWMAC_VISCONTI\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:365:\ttristate \"Toshiba Visconti DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-366-\tdefault ARCH_VISCONTI\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig=373=config STMMAC_LIBPCI\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-377-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:378:config DWMAC_INTEL\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-379-\ttristate \"Intel GMAC support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-387-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:388:config DWMAC_LOONGSON\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:389:\ttristate \"Loongson PCI DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-390-\tdefault MACH_LOONGSON64\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-397-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:398:config DWMAC_MOTORCOMM\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:399:\ttristate \"Motorcomm PCI DWMAC support\"\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-400-\tdepends on PCI\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-403-\thelp\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:404:\t  This enables glue driver for Motorcomm DWMAC-based PCI Ethernet\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-405-\t  controllers. Currently only YT6801 is supported.\n--\ndrivers/net/ethernet/stmicro/stmmac/Makefile=15=obj-$(CONFIG_STMMAC_PLATFORM)\t+= stmmac-platform.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:16:obj-$(CONFIG_DWMAC_ANARION)\t+= dwmac-anarion.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:17:obj-$(CONFIG_DWMAC_EIC7700)\t+= dwmac-eic7700.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:18:obj-$(CONFIG_DWMAC_INGENIC)\t+= dwmac-ingenic.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:19:obj-$(CONFIG_DWMAC_IPQ806X)\t+= dwmac-ipq806x.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:20:obj-$(CONFIG_DWMAC_LPC18XX)\t+= dwmac-lpc18xx.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:21:obj-$(CONFIG_DWMAC_MEDIATEK)\t+= dwmac-mediatek.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:22:obj-$(CONFIG_DWMAC_MESON)\t+= dwmac-meson.o dwmac-meson8b.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:23:obj-$(CONFIG_DWMAC_NUVOTON)\t+= dwmac-nuvoton.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:24:obj-$(CONFIG_DWMAC_QCOM_ETHQOS)\t+= dwmac-qcom-ethqos.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:25:obj-$(CONFIG_DWMAC_RENESAS_GBETH) += dwmac-renesas-gbeth.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:26:obj-$(CONFIG_DWMAC_ROCKCHIP)\t+= dwmac-rk.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:27:obj-$(CONFIG_DWMAC_RZN1)\t+= dwmac-rzn1.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:28:obj-$(CONFIG_DWMAC_S32)\t\t+= dwmac-s32.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:29:obj-$(CONFIG_DWMAC_SOCFPGA)\t+= dwmac-altr-socfpga.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:30:obj-$(CONFIG_DWMAC_SOPHGO)\t+= dwmac-sophgo.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:31:obj-$(CONFIG_DWMAC_SPACEMIT)\t+= dwmac-spacemit.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:32:obj-$(CONFIG_DWMAC_STARFIVE)\t+= dwmac-starfive.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:33:obj-$(CONFIG_DWMAC_STI)\t\t+= dwmac-sti.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:34:obj-$(CONFIG_DWMAC_STM32)\t+= dwmac-stm32.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:35:obj-$(CONFIG_DWMAC_SUNXI)\t+= dwmac-sunxi.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:36:obj-$(CONFIG_DWMAC_SUN8I)\t+= dwmac-sun8i.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:37:obj-$(CONFIG_DWMAC_SUN55I)\t+= dwmac-sun55i.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:38:obj-$(CONFIG_DWMAC_THEAD)\t+= dwmac-thead.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:39:obj-$(CONFIG_DWMAC_DWC_QOS_ETH)\t+= dwmac-dwc-qos-eth.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:40:obj-$(CONFIG_DWMAC_INTEL_PLAT)\t+= dwmac-intel-plat.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:41:obj-$(CONFIG_DWMAC_LOONGSON1)\t+= dwmac-loongson1.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:42:obj-$(CONFIG_DWMAC_GENERIC)\t+= dwmac-generic.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:43:obj-$(CONFIG_DWMAC_IMX8)\t+= dwmac-imx.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:44:obj-$(CONFIG_DWMAC_TEGRA)\t+= dwmac-tegra.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:45:obj-$(CONFIG_DWMAC_VISCONTI)\t+= dwmac-visconti.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile-46-stmmac-platform-objs:= stmmac_platform.o\n--\ndrivers/net/ethernet/stmicro/stmmac/Makefile=50=obj-$(CONFIG_STMMAC_PCI)\t+= stmmac-pci.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:51:obj-$(CONFIG_DWMAC_INTEL)\t+= dwmac-intel.o\ndrivers/net/ethernet/stmicro/stmmac/Makefile:52:obj-$(CONFIG_DWMAC_LOONGSON)\t+= dwmac-loongson.o\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/common.h-28-\ndrivers/net/ethernet/stmicro/stmmac/common.h:29:#define DWMAC_SNPSVER\tGENMASK_U32(7, 0)\ndrivers/net/ethernet/stmicro/stmmac/common.h:30:#define DWMAC_USERVER\tGENMASK_U32(15, 8)\ndrivers/net/ethernet/stmicro/stmmac/common.h-31-\ndrivers/net/ethernet/stmicro/stmmac/common.h-32-/* Synopsys Core versions */\ndrivers/net/ethernet/stmicro/stmmac/common.h:33:#define\tDWMAC_CORE_3_40\t\t0x34\ndrivers/net/ethernet/stmicro/stmmac/common.h:34:#define\tDWMAC_CORE_3_50\t\t0x35\ndrivers/net/ethernet/stmicro/stmmac/common.h:35:#define\tDWMAC_CORE_3_70\t\t0x37\ndrivers/net/ethernet/stmicro/stmmac/common.h:36:#define\tDWMAC_CORE_4_00\t\t0x40\ndrivers/net/ethernet/stmicro/stmmac/common.h:37:#define DWMAC_CORE_4_10\t\t0x41\ndrivers/net/ethernet/stmicro/stmmac/common.h:38:#define DWMAC_CORE_5_00\t\t0x50\ndrivers/net/ethernet/stmicro/stmmac/common.h:39:#define DWMAC_CORE_5_10\t\t0x51\ndrivers/net/ethernet/stmicro/stmmac/common.h:40:#define DWMAC_CORE_5_20\t\t0x52\ndrivers/net/ethernet/stmicro/stmmac/common.h-41-#define DWXGMAC_CORE_2_10\t0x21\n--\ndrivers/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/descs.h-3-  Header File to describe the DMA descriptors and related definitions.\ndrivers/net/ethernet/stmicro/stmmac/descs.h:4:  This is for DWMAC100 and 1000 cores.\ndrivers/net/ethernet/stmicro/stmmac/descs.h-5-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c-2-/*\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c:3: * Adaptrum Anarion DWMAC glue layer\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c-4- *\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c=133=module_platform_driver(anarion_dwmac_driver);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c-134-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c:135:MODULE_DESCRIPTION(\"Adaptrum Anarion DWMAC specific glue layer\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c-136-MODULE_AUTHOR(\"Alexandru Gagniuc \u003cmr.nuke.me@gmail.com\u003e\");\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c=36=static int dwc_eth_dwmac_config_dt(struct platform_device *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c-87-\t/* dwc-qos needs GMAC4, AAL, TSO and PMT */\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c:88:\tplat_dat-\u003ecore_type = DWMAC_CORE_GMAC4;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c-89-\tplat_dat-\u003edma_cfg-\u003eaal = 1;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-generic.c-1-/*\ndrivers/net/ethernet/stmicro/stmmac/dwmac-generic.c:2: * Generic DWMAC platform driver\ndrivers/net/ethernet/stmicro/stmmac/dwmac-generic.c-3- *\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-imx.c-2-/*\ndrivers/net/ethernet/stmicro/stmmac/dwmac-imx.c:3: * dwmac-imx.c - DWMAC Specific Glue layer for NXP imx8\ndrivers/net/ethernet/stmicro/stmmac/dwmac-imx.c-4- *\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-imx.c=403=MODULE_AUTHOR(\"NXP\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-imx.c:404:MODULE_DESCRIPTION(\"NXP imx8 DWMAC Specific Glue layer\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-imx.c-405-MODULE_LICENSE(\"GPL v2\");\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c-2-/*\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c:3: * dwmac-ingenic.c - Ingenic SoCs DWMAC specific glue layer\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c-4- *\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c=282=MODULE_AUTHOR(\"周琰杰 (Zhou Yanjie) \u003czhouyanjie@wanyeetech.com\u003e\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c:283:MODULE_DESCRIPTION(\"Ingenic SoCs DWMAC specific glue layer\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c-284-MODULE_LICENSE(\"GPL v2\");\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c-1-// SPDX-License-Identifier: GPL-2.0\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c:2:/* Intel DWMAC platform driver\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c-3- *\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c=150=MODULE_LICENSE(\"GPL v2\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c:151:MODULE_DESCRIPTION(\"Intel DWMAC platform driver\");\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=596=static void common_default_data(struct plat_stmmacenet_data *plat)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-599-\tplat-\u003eclk_csr = STMMAC_CSR_20_35M;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:600:\tplat-\u003ecore_type = DWMAC_CORE_GMAC;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-601-\tplat-\u003eforce_sf_dma_mode = true;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=616=static int intel_mgbe_common_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-626-\tplat-\u003eclk_csr = STMMAC_CSR_250_300M;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:627:\tplat-\u003ecore_type = DWMAC_CORE_GMAC4;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-628-\tplat-\u003eforce_sf_dma_mode = 0;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h-2-/* Copyright (c) 2020, Intel Corporation\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h:3: * DWMAC Intel header file\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h-4- */\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h-5-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h:6:#ifndef __DWMAC_INTEL_H__\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h:7:#define __DWMAC_INTEL_H__\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h-8-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h-80-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.h:81:#endif /* __DWMAC_INTEL_H__ */\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c=374=static int ipq806x_gmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c-475-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c:476:\tplat_dat-\u003ecore_type = DWMAC_CORE_GMAC;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c-477-\tplat_dat-\u003ebsp_priv = gmac;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c=508=MODULE_AUTHOR(\"Mathieu Olivari \u003cmathieu@codeaurora.org\u003e\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c:509:MODULE_DESCRIPTION(\"Qualcomm Atheros IPQ806x DWMAC specific glue layer\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c-510-MODULE_LICENSE(\"Dual BSD/GPL\");\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-72-#define PCI_DEVICE_ID_LOONGSON_GNET\t0x7a13\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:73:#define DWMAC_CORE_MULTICHAN_V1\t0x10\t/* Loongson custom ID 0x10 */\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:74:#define DWMAC_CORE_MULTICHAN_V2\t0x12\t/* Loongson custom ID 0x12 */\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-75-\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=86=static void loongson_default_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-95-\tplat-\u003eclk_csr = STMMAC_CSR_100_150M;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:96:\tplat-\u003ecore_type = DWMAC_CORE_GMAC;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-97-\tplat-\u003eforce_sf_dma_mode = true;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-108-\tswitch (ld-\u003eloongson_id) {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:109:\tcase DWMAC_CORE_MULTICHAN_V1:\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-110-\t\tld-\u003emultichan = 1;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-120-\t\tbreak;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:121:\tcase DWMAC_CORE_MULTICHAN_V2:\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-122-\t\tld-\u003emultichan = 1;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=306=static int loongson_dwmac_setup(void *apriv, struct mac_device_info *mac)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-328-\tif (ld-\u003emultichan) {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:329:\t\tpriv-\u003esynopsys_id = DWMAC_CORE_3_70;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-330-\t\t*dma = dwmac1000_dma_ops;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=466=static int loongson_dwmac_acpi_config(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-477-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:478:/* Loongson's DWMAC device may take nearly two seconds to complete DMA reset */\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-479-static int loongson_dwmac_fix_reset(struct stmmac_priv *priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=614=module_pci_driver(loongson_dwmac_driver);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-615-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:616:MODULE_DESCRIPTION(\"Loongson DWMAC PCI driver\");\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-617-MODULE_AUTHOR(\"Qing Zhang \u003czhangqing@loongson.cn\u003e\");\n--\n\n"
}

gemini-3.1-pro-preview

null

null

							input: 25160
							output: 21
							thoughts: 212
						

**Analyzing the STMMAC Driver and its QEMU Representation**

Okay, so I need to understand this `stmmac` driver a bit better, and how it relates to the `DWMAC` (DesignWare MAC) as it seems that `stmmac` is, in fact, the driver for `DWMAC`. I remember seeing something about this in QEMU, so let's check `hw/net/designware.c`. I'm going to quickly ascertain which QEMU machines actually utilize this specific piece of code. Hmm, looks like it's used in `hw/arm/allwinner-h3.c`, but wait, the sun8i-emac is different here. Let's see... oh, also, designware *is* used, but in `hw/arm/xlnx-zynqmp.c`? No, that's `cadence_gem`. Okay, I was getting that confused.

Now, where was I? Right, `stmmac`. I also recall seeing that `stmmac` is tested by syzkaller. That's good, because syzkaller provides valuable coverage data. So, let's investigate the reachability of `stmmac_select_queue`. This patch seems to be modifying `stmmac_select_queue`. And, let's see, that function is the `ndo_select_queue` callback for the `stmmac` driver. Gotta confirm this quickly. Going to check `stmmac_main.c` to be completely sure.

{
  "Expression": "stmmac_select_queue"
}

{
  "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_main.c=6419=static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6444-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6445:static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6446-\t\t\t       struct net_device *sb_dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7303=static const struct net_device_ops stmmac_netdev_ops = {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7315-\t.ndo_setup_tc = stmmac_setup_tc,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7316:\t.ndo_select_queue = stmmac_select_queue,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7317-\t.ndo_set_mac_address = stmmac_set_mac_address,\n"
}

gemini-3.1-pro-preview

null

null

							input: 26105
							output: 22
							thoughts: 441
						

**Analyzing the Reachability of `ndo_select_queue` in `stmmac` for Fuzzing**

Okay, so I'm pretty sure we're talking about the `ndo_select_queue` callback here. That's the function called when the network device has multiple transmit queues and it's time to decide which one to use for a packet. The critical question is, can we actually reach this in a virtualized fuzzing environment? If syzkaller is targeting `stmmac`, then yes. If syzkaller can test it via `vnet`, or `dummy`, or a platform device probed in QEMU, then it's reachable.

Now, does syzkaller test `stmmac`? I can quickly check the syzkaller configs to see if `stmmac` is enabled. Let's see if `CONFIG_STMMAC_ETH` is set in the `x86_64` defconfig or the main syzkaller config. Hmmm, I don't have the syzkaller config handy, but wait, I can check if it's a PCI device. `stmmac_pci.c` registers a PCI driver.

Okay, syzkaller *can* fuzz PCI devices, using `syz_pci_device` or similar, or QEMU can emulate the PCI device. Wait...does QEMU emulate the `stmmac` PCI device? No, that's not something QEMU implements. But hang on, syzkaller has `vhci` for USB, `mac80211_hwsim` for wifi, and `netdevsim` for net. So, does syzkaller have a *pseudo* device for PCI? No, it's not the same thing. Syzkaller's `syz_pci_device` injects PCI devices, providing the PCI config space and BARs to probe the driver. But to actually get to `ndo_select_queue` and send packets, the device needs to be registered as a netdev and be up.

Okay, so can `stmmac` probe successfully with just random BARs provided by `syz_pci_device`? That seems unlikely, but it's worth checking `stmmac_pci_probe` to see.

{
  "Expression": "stmmac_pci_probe"
}

{
  "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=102=static const struct stmmac_pci_info snps_gmac5_pci_info = {\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)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=212=static struct pci_driver stmmac_pci_driver = {\n--\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,\n"
}

gemini-3.1-pro-preview

null

null

							input: 27519
							output: 51
							thoughts: 17
						

Okay, here's the summary, rendered as a first-person thought process, keeping in mind the user is an expert:

**Diving into `stmmac_pci_probe`**

Alright, let's get down to brass tacks. I need to understand what `stmmac_pci_probe` is actually doing. Given my experience, I'm assuming this is the primary entry point for the PCI-based STMMAC driver instantiation. It's the function called when the kernel detects an STMMAC Ethernet controller via PCI. So, what are the key steps it's likely taking? I expect it'll be doing things like:

*   **Resource Allocation:** First, it will likely be probing the PCI configuration space to find the base address for the STMMAC's registers, interrupt numbers, and other necessary resources. It'll be a critical part of discovering how this card is hooked up.
*   **Driver Binding:** It'll then have to bind to the PCI device, likely using functions like `pci_set_drvdata` to attach the driver-specific data to the PCI device struct. I anticipate it's a routine call that's essential for getting this driver running and for linking it to the hardware.
*   **Device Initialization:** This will include allocating a platform device struct, filling it with the PCI-derived resource information, and possibly calling into platform device drivers. This will then likely result in calling `platform_device_add` or similar. I'll need to see how these initializations and calls are linked to see where the driver is hooked up.
*   **DMA Setup:** I'm guessing it will configure DMA settings and likely allocate DMA-able memory regions for transmit and receive buffers. Given the architecture of an STMMAC, this is going to be central to high-speed operation.
*   **Interrupt Handling:** Setting up the interrupt handler via the PCI interrupt vector is a given. I'll need to look at how it's handled, including interrupt masking and priority.
*   **Clocks and Reset:** I'll also expect it to manage clock enabling/disabling for the MAC and potentially apply resets. STMMACs often require careful clock management.
*   **Network Device Registration:** Finally, it'll almost certainly call `register_netdev` to create a network interface and make it available to the networking stack. This is the last step to make the network controller available to the kernel and the userland.

I need to see the implementation to verify these assumptions and to better understand any nuances or optimizations the developers used. I have a lot of practical experience and this will tell me if the code is doing what I expect. Let's see how it's being done.

{
  "File": "drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c",
  "FirstLine": 118,
  "LineCount": 100
}

{
  "Contents": " 118:\tstatic int stmmac_pci_probe(struct pci_dev *pdev,\n 119:\t\t\t\t    const struct pci_device_id *id)\n 120:\t{\n 121:\t\tstruct stmmac_pci_info *info = (struct stmmac_pci_info *)id-\u003edriver_data;\n 122:\t\tstruct plat_stmmacenet_data *plat;\n 123:\t\tstruct stmmac_resources res = {};\n 124:\t\tint ret;\n 125:\t\tint i;\n 126:\t\n 127:\t\tplat = stmmac_plat_dat_alloc(\u0026pdev-\u003edev);\n 128:\t\tif (!plat)\n 129:\t\t\treturn -ENOMEM;\n 130:\t\n 131:\t\tplat-\u003emdio_bus_data = devm_kzalloc(\u0026pdev-\u003edev,\n 132:\t\t\t\t\t\t   sizeof(*plat-\u003emdio_bus_data),\n 133:\t\t\t\t\t\t   GFP_KERNEL);\n 134:\t\tif (!plat-\u003emdio_bus_data)\n 135:\t\t\treturn -ENOMEM;\n 136:\t\n 137:\t\tplat-\u003esafety_feat_cfg = devm_kzalloc(\u0026pdev-\u003edev,\n 138:\t\t\t\t\t\t     sizeof(*plat-\u003esafety_feat_cfg),\n 139:\t\t\t\t\t\t     GFP_KERNEL);\n 140:\t\tif (!plat-\u003esafety_feat_cfg)\n 141:\t\t\treturn -ENOMEM;\n 142:\t\n 143:\t\t/* Enable pci device */\n 144:\t\tret = pcim_enable_device(pdev);\n 145:\t\tif (ret) {\n 146:\t\t\tdev_err(\u0026pdev-\u003edev, \"%s: ERROR: failed to enable device\\n\",\n 147:\t\t\t\t__func__);\n 148:\t\t\treturn ret;\n 149:\t\t}\n 150:\t\n 151:\t\t/* Get the base address of device */\n 152:\t\tfor (i = 0; i \u003c PCI_STD_NUM_BARS; i++) {\n 153:\t\t\tif (pci_resource_len(pdev, i) == 0)\n 154:\t\t\t\tcontinue;\n 155:\t\t\tres.addr = pcim_iomap_region(pdev, i, STMMAC_RESOURCE_NAME);\n 156:\t\t\tif (IS_ERR(res.addr))\n 157:\t\t\t\treturn PTR_ERR(res.addr);\n 158:\t\t\tbreak;\n 159:\t\t}\n 160:\t\n 161:\t\tpci_set_master(pdev);\n 162:\t\n 163:\t\tret = info-\u003esetup(pdev, plat);\n 164:\t\tif (ret)\n 165:\t\t\treturn ret;\n 166:\t\n 167:\t\tres.wol_irq = pdev-\u003eirq;\n 168:\t\tres.irq = pdev-\u003eirq;\n 169:\t\n 170:\t\tplat-\u003esafety_feat_cfg-\u003etsoee = 1;\n 171:\t\tplat-\u003esafety_feat_cfg-\u003emrxpee = 1;\n 172:\t\tplat-\u003esafety_feat_cfg-\u003emestee = 1;\n 173:\t\tplat-\u003esafety_feat_cfg-\u003emrxee = 1;\n 174:\t\tplat-\u003esafety_feat_cfg-\u003emtxee = 1;\n 175:\t\tplat-\u003esafety_feat_cfg-\u003eepsi = 1;\n 176:\t\tplat-\u003esafety_feat_cfg-\u003eedpp = 1;\n 177:\t\tplat-\u003esafety_feat_cfg-\u003eprtyen = 1;\n 178:\t\tplat-\u003esafety_feat_cfg-\u003etmouten = 1;\n 179:\t\n 180:\t\tplat-\u003esuspend = stmmac_pci_plat_suspend;\n 181:\t\tplat-\u003eresume = stmmac_pci_plat_resume;\n 182:\t\n 183:\t\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat, \u0026res);\n 184:\t}\n 185:\t\n 186:\t/**\n 187:\t * stmmac_pci_remove\n 188:\t *\n 189:\t * @pdev: platform device pointer\n 190:\t * Description: this function calls the main to free the net resources.\n 191:\t */\n 192:\tstatic void stmmac_pci_remove(struct pci_dev *pdev)\n 193:\t{\n 194:\t\tstmmac_dvr_remove(\u0026pdev-\u003edev);\n 195:\t}\n 196:\t\n 197:\t/* synthetic ID, no official vendor */\n 198:\t#define PCI_VENDOR_ID_STMMAC\t\t0x0700\n 199:\t\n 200:\t#define PCI_DEVICE_ID_STMMAC_STMMAC\t\t0x1108\n 201:\t#define PCI_DEVICE_ID_SYNOPSYS_GMAC5_ID\t\t0x7102\n 202:\t\n 203:\tstatic const struct pci_device_id stmmac_id_table[] = {\n 204:\t\t{ PCI_DEVICE_DATA(STMMAC, STMMAC, \u0026stmmac_pci_info) },\n 205:\t\t{ PCI_DEVICE_DATA(STMICRO, MAC, \u0026stmmac_pci_info) },\n 206:\t\t{ PCI_DEVICE_DATA(SYNOPSYS, GMAC5_ID, \u0026snps_gmac5_pci_info) },\n 207:\t\t{}\n 208:\t};\n 209:\t\n 210:\tMODULE_DEVICE_TABLE(pci, stmmac_id_table);\n 211:\t\n 212:\tstatic struct pci_driver stmmac_pci_driver = {\n 213:\t\t.name = STMMAC_RESOURCE_NAME,\n 214:\t\t.id_table = stmmac_id_table,\n 215:\t\t.probe = stmmac_pci_probe,\n 216:\t\t.remove = stmmac_pci_remove,\n 217:\t\t.driver         = {\n"
}

gemini-3.1-pro-preview

null

null

							input: 29820
							output: 22
							thoughts: 26
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing the Probe Function Call**

Alright, the code's calling `stmmac_dvr_probe`. My immediate instinct is to dive into that function, see what's happening within it. I need to understand the probe routine for this STMMAC driver. I need to see how it's initialized, if it is using any of the available resources. This is where the core device setup should be. Let's see how it's interacting with the hardware and any associated configuration data. I'm looking for the essential steps it takes to identify, initialize, and claim the hardware.

{
  "Expression": "stmmac_dvr_probe"
}

{
  "Output": "drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c=283=static int dwc_eth_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c-329-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c:330:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c-331-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c=42=static int intel_eth_plat_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c-117-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c:118:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c-119-\tif (ret)\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-1340-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1341:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat, \u0026res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1342-\tif (ret) {\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c=374=static int ipq806x_gmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c-482-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c:483:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c-484-\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-561-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:562:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat, \u0026res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-563-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-lpc18xx.c=42=static int lpc18xx_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-lpc18xx.c-67-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-lpc18xx.c:68:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-lpc18xx.c-69-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c=599=static int mediatek_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c-641-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c:642:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c-643-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson.c=47=static int meson6_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson.c-72-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:73:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson.c-74-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c=382=static int meson8b_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c-463-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c:464:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c-465-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c=293=static int motorcomm_probe(struct pci_dev *pdev, const struct pci_device_id *id)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-358-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c:359:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat, \u0026res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c-360-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c=48=static int rzn1_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c-67-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c:68:\tret = stmmac_dvr_probe(dev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c-69-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c=35=static int sophgo_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c-64-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c:65:\treturn stmmac_dvr_probe(dev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c-66-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c=147=static int spacemit_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c-206-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c:207:\treturn stmmac_dvr_probe(dev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c-208-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c=90=static int starfive_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c-152-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c:153:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c-154-}\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c=525=static int stm32_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c-578-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c:579:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c-580-\tif (ret)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c=1105=static int sun8i_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c-1201-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:1202:\t/* the MAC is runtime suspended after stmmac_dvr_probe(), so we\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c-1203-\t * need to ensure the MAC resume back before other operations such\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c-1208-\t/* The mux must be registered after parent MDIO\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:1209:\t * so after stmmac_dvr_probe()\ndrivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c-1210-\t */\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-375-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c:376:\terr = stmmac_dvr_probe(\u0026pdev-\u003edev, plat, \u0026res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c-377-\tif (err \u003c 0)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c=205=static int visconti_eth_dwmac_probe(struct platform_device *pdev)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c-236-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c:237:\tret = stmmac_dvr_probe(\u0026pdev-\u003edev, plat_dat, \u0026stmmac_res);\ndrivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c-238-\tif (ret)\n--\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,\ndrivers/net/ethernet/stmicro/stmmac/stmmac.h-415-\t\t     struct plat_stmmacenet_data *plat_dat,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7787=EXPORT_SYMBOL_GPL(stmmac_plat_dat_alloc);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7788-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7789:static int __stmmac_dvr_probe(struct device *device,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7790-\t\t\t      struct plat_stmmacenet_data *plat_dat,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8091-/**\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8092: * stmmac_dvr_probe\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8093- * @dev: device pointer\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8100- */\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8101:int stmmac_dvr_probe(struct device *dev, struct plat_stmmacenet_data *plat_dat,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8102-\t\t     struct stmmac_resources *res)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8111-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8112:\tret = __stmmac_dvr_probe(dev, plat_dat, res);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8113-\tif (ret \u0026\u0026 plat_dat-\u003eexit)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8117-}\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:8118:EXPORT_SYMBOL_GPL(stmmac_dvr_probe);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-8119-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=118=static int stmmac_pci_probe(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-182-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:183:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat, \u0026res);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-184-}\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c=848=int stmmac_pltfr_probe(struct platform_device *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-856-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:857:\treturn stmmac_dvr_probe(\u0026pdev-\u003edev, plat, res);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_platform.c-858-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 34126
							output: 24
							thoughts: 727
						

**Analyzing the stmmac Driver and Identifying Fuzzing Targets**

Okay, so I've been looking at this `stmmac` driver code, specifically how it handles queue selection. It seems that `stmmac_dvr_probe` eventually calls `__stmmac_dvr_probe`, which registers the network device. The crucial point here is the interaction with `syzkaller`, using `syz_pci_device` to inject a PCI device with the right vendor and device IDs. This means we can definitely get the driver to bind to this device in a virtualized environment, map the BARs, register the netdev, and then, crucially, send packets through it. That gets us to `stmmac_select_queue`. This code is definitely reachable and testable.

Now, about the patch itself. It's modifying `stmmac_select_queue`. Before the patch, the code would use a hardcoded value of `0` if TSO/USO was in use, now it's selecting a queue with `netdev_pick_tx` and verifying if the selected queue is permitted for TSO. If not, it falls back to queue 0. So it's a functional change in the driver's core logic.

My initial thought was to fuzz `stmmac_select_queue`. It's a hot-path function; it gets called for every transmitted packet. But then I remember the prompt's guideline: avoid generic hot-path functions, prioritize non-static entrypoints over internal helper functions. Oops! `stmmac_select_queue` is a static function. That's a problem.

So, I need to find a better target. Maybe `stmmac_tso_channel_permitted`? Let's check if it's static. That would be a better target for fuzzing based on the prompt's guidelines.

{
  "Expression": "stmmac_tso_channel_permitted"
}

{
  "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_main.c=3604=static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3618- */\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3619:static bool stmmac_tso_channel_permitted(struct stmmac_priv *priv,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3620-\t\t\t\t\t unsigned int chan)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=3638=static int stmmac_hw_setup(struct net_device *dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3713-\t\tfor (chan = 0; chan \u003c tx_cnt; chan++) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3714:\t\t\tif (!stmmac_tso_channel_permitted(priv, chan))\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3715-\t\t\t\tcontinue;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=4984=static netdev_features_t stmmac_features_check(struct sk_buff *skb,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-5005-\tif (skb_is_gso(skb)) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:5006:\t\tif (!stmmac_tso_channel_permitted(priv, queue) ||\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-5007-\t\t    !stmmac_tso_valid_packet(skb))\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=6445=static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6451-\tif ((skb_shinfo(skb)-\u003egso_type \u0026 priv-\u003egso_enabled_types) \u0026\u0026\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6452:\t    !stmmac_tso_channel_permitted(priv, queue)) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6453-\t\t/* GSO frames need HW TSO/USO, which cannot run on TBS queues.\n"
}

gemini-3.1-pro-preview

null

null

							input: 36028
							output: 19
							thoughts: 439
						

**Focusing on the stmmac Driver Patch**

Okay, so I'm analyzing this patch. First thought: `stmmac_tso_channel_permitted` is static, which is interesting but probably not relevant here. Then I see `stmmac_select_queue` is *also* static. Hmm, is *anything* non-static? The patch *only* modifies `stmmac_select_queue`, which is a bit of a concern. It's a hot-path function because it's used by `ndo_select_queue`. The instructions say to avoid generic hot-path functions in `FocusSymbols` to prevent skewed test distributions. If I don't list anything, Syzkaller will just use the coverage from the patch.

Wait a second… the prompt *also* wants specific kernel functions that should be heavily fuzzed, and prefers non-static entrypoints. Is `stmmac_select_queue` a *generic* hot-path? No, it's specific to the stmmac driver. It's not like `dev_queue_xmit` which is *very* generic. Even though it's hot-path for *this* driver, it's not a kernel-wide bottleneck.

Let me think… is there any other function impacted? No, just `stmmac_select_queue`. Okay, one more check: is it inlined? Since it's passed as a function pointer to `ndo_select_queue`, it's *not* inlined. Perfect. I'll list `stmmac_select_queue` in `FocusSymbols`. That's the right choice.

Now, for CONFIGs. What do I need to actually *test* this via PCI? I think it's `CONFIG_STMMAC_ETH` and `CONFIG_STMMAC_PCI`, but let me double-check `drivers/net/ethernet/stmicro/stmmac/Kconfig` just to be certain of the exact names.

{
  "Expression": "config STMMAC_"
}

{
  "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--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig=18=if STMMAC_ETH\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-19-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:20:config STMMAC_SELFTESTS\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-21-\tbool \"Support for STMMAC Selftests\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-28-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:29:config STMMAC_PLATFORM\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-30-\ttristate \"STMMAC Platform bus support\"\n--\ndrivers/net/ethernet/stmicro/stmmac/Kconfig=371=endif # STMMAC_PLATFORM\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-372-\ndrivers/net/ethernet/stmicro/stmmac/Kconfig:373:config STMMAC_LIBPCI\ndrivers/net/ethernet/stmicro/stmmac/Kconfig-374-\ttristate\n--\ndrivers/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"
}

gemini-3.1-pro-preview

null

null

							input: 37446
							output: 20
							thoughts: 57
						

Okay, let's break this down.

**Analyzing STMMAC Configuration Dependencies**

Alright, so I see `STMMAC_ETH` and `STMMAC_PCI` as the key configurations here. My initial thought is to understand their relationship. Ah, a dependency! `STMMAC_PCI` relies on both `PCI` and `STMMAC_ETH`. Given my expertise, I already know what implications a dependency like this has. It's time to dive deeper and clarify the nature of these relationships, so let me immediately check the specifics surrounding `STMMAC_PCI` and its dependencies. I'll need to understand if this is a hard dependency, a soft one, and what consequences the other configurations will bring.

{
  "Expression": "config STMMAC_PCI"
}

{
  "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"
}

gemini-3.1-pro-preview

null

null

							input: 37806
							output: 44
							thoughts: 29
						

Here's my take on the thought process, as requested:

**Navigating the STMMAC Ethernet Driver Configuration**

Okay, so I'm digging into the configuration options for the STMMAC Ethernet driver, specifically the `Kconfig` file. I'm thinking, line 407 seems like a good place to start, given the general structure of these files. That section is likely going to hold some important clues about what features are available, how they're enabled, and potentially any dependencies or build-time considerations for this particular STMicroelectronics MAC controller implementation. I'm expecting to find details around various PHY types, hardware acceleration options, or maybe even different variants of the STMMAC itself. Let's get to the specifics and see what's on offer there.

{
  "File": "drivers/net/ethernet/stmicro/stmmac/Kconfig",
  "FirstLine": 395,
  "LineCount": 20
}

{
  "Contents": " 395:\t\t  This selects the LOONGSON PCI bus support for the stmmac driver,\n 396:\t\t  Support for ethernet controller on Loongson-2K1000 SoC and LS7A1000 bridge.\n 397:\t\n 398:\tconfig DWMAC_MOTORCOMM\n 399:\t\ttristate \"Motorcomm PCI DWMAC support\"\n 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"
}

gemini-3.1-pro-preview

null

null

							input: 38377
							output: 42
							thoughts: 58
						

**Analyzing STMMAC Configuration Options**

Okay, so I'm looking at these STMMAC configurations – `STMMAC_ETH` and `STMMAC_PCI`. My immediate thought is, "Right, let's dissect the dependencies." Specifically, I need to understand what `STMMAC_ETH` relies on. Ah, here we are: `STMMAC_ETH` has a dependency on both `HAS_IOMEM` and `HAS_DMA`. Got it. Now, I need to dig deeper into those. What is actually *requiring* those options? I need to understand the implications of enabling `STMMAC_ETH`, and those dependencies are the critical path.

{
  "File": "drivers/net/ethernet/stmicro/stmmac/Kconfig",
  "FirstLine": 1,
  "LineCount": 20
}

{
  "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"
}

gemini-3.1-pro-preview

null

null

							input: 38879
							output: 89
							thoughts: 462
						

**My Assessment of the STMMAC Driver Patch**

Okay, so I've looked over this patch to the STMicroelectronics DWMAC driver, and I think I have a good handle on it. The key is understanding that it modifies the `stmmac_select_queue` function. It's clear that the driver can be probed either through PCI (`STMMAC_PCI`) or platform devices. And Syzkaller can test it using `syz_pci_device` or `syz_platform_device`, which is good.

The functional impact seems to be a change in how the driver handles queue selection specifically for GSO frames. That makes it worth fuzzing, definitely.

The question that popped into my head was whether `stmmac_select_queue` is a hot-path function. Thinking about it, since it's called for every transmitted packet, it *is* a hot-path. The prompt specifically warns against listing generic hot-path functions to avoid biasing the testing. However, after thinking it through, I've decided to list it. It's not a generic kernel function like `dev_queue_xmit` or `kmalloc`. It's *specific* to the STMMAC driver, and it's the only function that's modified by the patch. Even if Syzkaller will pick it up through coverage without listing it, explicitly calling it out focuses the fuzzing.

I've double-checked, and yes, `stmmac_select_queue` is the *only* function changed.

So, I will call `set-results` with the following:

*   **WorthFuzzing: True**
*   **FocusSymbols: \["stmmac\_select\_queue"\]**
*   **EnableConfigs: \["STMMAC\_ETH", "STMMAC\_PCI"\]**
*   **Reasoning: "The patch modifies the queue selection logic for GSO frames in the STMicroelectronics DWMAC driver. The driver can be probed via PCI and tested in virtualized environments."**

That should cover everything.

{
  "EnableConfigs": [
    "STMMAC_ETH",
    "STMMAC_PCI"
  ],
  "FocusSymbols": [
    "stmmac_select_queue"
  ],
  "Reasoning": "The patch modifies the queue selection logic for GSO frames in the STMicroelectronics DWMAC driver. The driver can be probed via PCI and tested in virtualized environments.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "STMMAC_ETH",
    "STMMAC_PCI"
  ],
  "FocusSymbols": [
    "stmmac_select_queue"
  ],
  "Reasoning": "The patch modifies the queue selection logic for GSO frames in the STMicroelectronics DWMAC driver. The driver can be probed via PCI and tested in virtualized environments.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch modifies the logic for selecting a transmission queue for network packets (sk_buff) in the stmmac driver. It checks the `gso_type` of the packet against `priv-\u003egso_enabled_types` and verifies if the selected queue permits TSO via `stmmac_tso_channel_permitted()`. These changes only affect control flow and queue selection based on already initialized fields in the `sk_buff` and the driver's private data structure. There are no new allocations, no structures copied to user space, and no risk of exposing uninitialized memory. Any potential bugs introduced by this patch would be related to incorrect queue selection or out-of-bounds queue indices, which are effectively caught by standard KASAN and other bug detectors. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}

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.

For your convenience, here is the diff of the changes:
commit 019f53ec44f68222b12021684ca06a008c14dd1c
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Aug 7 15:34:19 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b2b7d0242dd3c..99fc7313f247e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6445,19 +6445,18 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,
 static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,
 			       struct net_device *sb_dev)
 {
-	int gso = skb_shinfo(skb)->gso_type;
+	u32 queue = netdev_pick_tx(dev, skb, NULL) % dev->real_num_tx_queues;
+	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if (gso & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6 | SKB_GSO_UDP_L4)) {
-		/*
-		 * There is no way to determine the number of TSO/USO
-		 * capable Queues. Let's use always the Queue 0
-		 * because if TSO/USO is supported then at least this
-		 * one will be capable.
+	if ((skb_shinfo(skb)->gso_type & priv->gso_enabled_types) &&
+	    !stmmac_tso_channel_permitted(priv, queue)) {
+		/* GSO frames need HW TSO/USO, which cannot run on TBS queues.
+		 * Fall back to the queue reserved for TSO (queue 0).
 		 */
 		return 0;
 	}
 
-	return netdev_pick_tx(dev, skb, NULL) % dev->real_num_tx_queues;
+	return queue;
 }
 
 static int stmmac_set_mac_address(struct net_device *ndev, void *addr)

gemini-3.1-pro-preview

null

null

							input: 2353
							output: 44
							thoughts: 655
						

**Analyzing the stmmac Queue Selection Patch**

Okay, so I'm looking at this patch for `stmmac_select_queue` within the STMicroelectronics Ethernet driver. The core of this function is about determining which transmit queue a given `sk_buff` (socket buffer) should be assigned to. My initial thought is to understand the change in logic and its potential implications, particularly in terms of memory safety and performance.

The original code's approach was straightforward: if the `sk_buff` indicated it was a Generic Segmentation Offload (GSO) packet (specifically TCPv4, TCPv6, or UDP L4), it would *always* default to queue 0. Otherwise, it would use `netdev_pick_tx` to select a queue, modulo the number of real transmit queues. This has the effect of assigning a queue in a round robin fashion, while prioritizing TSO traffic to a single queue.

The patch introduces a more nuanced approach. Now, the logic checks if a few conditions hold:
1.  The `sk_buff` is a GSO packet (which is unchanged).
2.  The `gso_type` within the `sk_buff` matches the `priv->gso_enabled_types` and
3.  The proposed queue is NOT permitted for TSO.

If those three conditions hold, the function falls back to queue 0. This suggests there is some hardware-specific configuration related to TSO (TCP Segmentation Offload) or USO (UDP Segmentation Offload) capabilities. In other words, if the packet is a GSO packet of a type handled by hardware TSO/USO, and the chosen queue does not support hardware TSO/USO, then queue 0 is chosen.

My main concern is always memory safety. However, after reviewing the code, it seems the patch is quite localized. No new data structures are being allocated, and no kernel data is being leaked to user space. It only reads the values in `skb_shinfo(skb)->gso_type` and `priv->gso_enabled_types`. The `skb_shinfo(skb)->gso_type` is populated by the networking stack so it's guaranteed to be initialized. `priv->gso_enabled_types` is driver-initialized. The values will already exist before this function is called. So, from a quick inspection, there are no immediate uninitialized memory risks. The patch simply modifies *how* a queue is selected. The `NeedsKMSAN` flag can be set to false.

To be absolutely sure, it's worth a quick look at `stmmac_tso_channel_permitted` to confirm that it does not have any potential for memory safety issues.

{
  "Expression": "stmmac_tso_channel_permitted",
  "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/"
}

{
  "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_main.c=3604=static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3618- */\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3619:static bool stmmac_tso_channel_permitted(struct stmmac_priv *priv,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3620-\t\t\t\t\t unsigned int chan)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=3638=static int stmmac_hw_setup(struct net_device *dev)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3713-\t\tfor (chan = 0; chan \u003c tx_cnt; chan++) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3714:\t\t\tif (!stmmac_tso_channel_permitted(priv, chan))\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-3715-\t\t\t\tcontinue;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=4984=static netdev_features_t stmmac_features_check(struct sk_buff *skb,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-5005-\tif (skb_is_gso(skb)) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:5006:\t\tif (!stmmac_tso_channel_permitted(priv, queue) ||\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-5007-\t\t    !stmmac_tso_valid_packet(skb))\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=6445=static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6451-\tif ((skb_shinfo(skb)-\u003egso_type \u0026 priv-\u003egso_enabled_types) \u0026\u0026\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:6452:\t    !stmmac_tso_channel_permitted(priv, queue)) {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-6453-\t\t/* GSO frames need HW TSO/USO, which cannot run on TBS queues.\n"
}

gemini-3.1-pro-preview

null

null

							input: 4382
							output: 199
							thoughts: 58
						

**Analyzing the `stmmac_tso_channel_permitted` Function**

Okay, so I've looked at this `stmmac_tso_channel_permitted` function. Seems pretty straightforward, almost certainly just a boolean check. I'm guessing it's probing some configuration flag related to whether the channel is set up for Time Based Scheduling, or something analogous. No red flags here – I'm not seeing any indication of uninitialized memory being touched, which is always a relief. Given that, I'm confident we can safely set `NeedsKMSAN=false` for this one. It looks like we're in the clear.

{
  "KMSANReasoning": "The patch modifies the logic for selecting a transmission queue for network packets (sk_buff) in the stmmac driver. It checks the `gso_type` of the packet against `priv-\u003egso_enabled_types` and verifies if the selected queue permits TSO via `stmmac_tso_channel_permitted()`. These changes only affect control flow and queue selection based on already initialized fields in the `sk_buff` and the driver's private data structure. There are no new allocations, no structures copied to user space, and no risk of exposing uninitialized memory. Any potential bugs introduced by this patch would be related to incorrect queue selection or out-of-bounds queue indices, which are effectively caught by standard KASAN and other bug detectors. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch modifies the logic for selecting a transmission queue for network packets (sk_buff) in the stmmac driver. It checks the `gso_type` of the packet against `priv-\u003egso_enabled_types` and verifies if the selected queue permits TSO via `stmmac_tso_channel_permitted()`. These changes only affect control flow and queue selection based on already initialized fields in the `sk_buff` and the driver's private data structure. There are no new allocations, no structures copied to user space, and no risk of exposing uninitialized memory. Any potential bugs introduced by this patch would be related to incorrect queue selection or out-of-bounds queue indices, which are effectively caught by standard KASAN and other bug detectors. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}