AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the Airoha NPU driver (drivers/net/ethernet/airoha/airoha_npu.c), which is a vendor-specific SoC platform driver. This hardware is not emulated in standard QEMU or virtualized environments, making the code unreachable during fuzzing.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit ca5bc19e9d633447599edd14ca8f5d9af8f87899\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Aug 9 16:15:52 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c\nindex b679bed952de3..c839e0a419aa5 100644\n--- a/drivers/net/ethernet/airoha/airoha_npu.c\n+++ b/drivers/net/ethernet/airoha/airoha_npu.c\n@@ -23,6 +23,12 @@\n #define NPU_EN7581_FIRMWARE_RV32_MAX_SIZE\t0x200000\n #define NPU_EN7581_FIRMWARE_DATA_MAX_SIZE\t0x10000\n #define NPU_DUMP_SIZE\t\t\t\t512\n+/*\n+ * Mailbox DMA payload size. Covers sizeof(struct ppe_mbox_data) (28) and\n+ * WLAN TLV messages (header + payload); largest in-tree WLAN payload today\n+ * is 16 bytes (INODE_TXRX_REG_ADDR). Keep headroom for future commands.\n+ */\n+#define AIROHA_NPU_MBOX_SIZE\t\t\t256\n \n #define REG_NPU_LOCAL_SRAM\t\t0x0\n \n@@ -160,23 +166,34 @@ struct wlan_mbox_data {\n \tDECLARE_FLEX_ARRAY(u8, d);\n };\n \n-static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,\n-\t\t\t       void *p, int size)\n+static int __airoha_npu_send_msg(struct airoha_npu *npu, int func_id,\n+\t\t\t\t const void *data, int len, void *reply,\n+\t\t\t\t u16 reply_len)\n {\n-\tu16 core = 0; /* FIXME */\n-\tu32 val, offset = core \u003c\u003c 4;\n-\tdma_addr_t dma_addr;\n+\tstruct airoha_npu_core *core = \u0026npu-\u003ecores[0]; /* FIXME: core */\n+\tu32 val, offset = 0;\n \tint ret;\n \n-\tdma_addr = dma_map_single(npu-\u003edev, p, size, DMA_BIDIRECTIONAL);\n-\tret = dma_mapping_error(npu-\u003edev, dma_addr);\n-\tif (ret)\n-\t\treturn ret;\n+\tif (len \u003e AIROHA_NPU_MBOX_SIZE)\n+\t\treturn -EINVAL;\n+\n+\tif (reply \u0026\u0026 reply_len \u003e len)\n+\t\treturn -EINVAL;\n+\n+\t/*\n+\t * Mailbox payloads are bidirectional (CPU request, NPU response).\n+\t * On EN7581+MT7996, streaming DMA_BIDIRECTIONAL against the\n+\t * caller kzalloc() buffer can leave WLAN_FUNC_GET_WAIT_NPU_VERSION\n+\t * reading as 0.0 despite MBOX success. Reuse a probe-time coherent\n+\t * bounce buffer under the per-core lock (also used from PPE\n+\t * foe_commit under atomic context).\n+\t */\n+\tspin_lock_bh(\u0026core-\u003elock);\n \n-\tspin_lock_bh(\u0026npu-\u003ecores[core].lock);\n+\tmemcpy(core-\u003ebuf, data, len);\n \n-\tregmap_write(npu-\u003eregmap, REG_CR_MBQ0_CTRL(0) + offset, dma_addr);\n-\tregmap_write(npu-\u003eregmap, REG_CR_MBQ0_CTRL(1) + offset, size);\n+\tregmap_write(npu-\u003eregmap, REG_CR_MBQ0_CTRL(0) + offset, core-\u003eaddr);\n+\tregmap_write(npu-\u003eregmap, REG_CR_MBQ0_CTRL(1) + offset, len);\n \tregmap_read(npu-\u003eregmap, REG_CR_MBQ0_CTRL(2) + offset, \u0026val);\n \tregmap_write(npu-\u003eregmap, REG_CR_MBQ0_CTRL(2) + offset, val + 1);\n \tval = FIELD_PREP(MBOX_MSG_FUNC_ID, func_id) | MBOX_MSG_WAIT_RSP;\n@@ -189,13 +206,21 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,\n \tif (!ret \u0026\u0026 FIELD_GET(MBOX_MSG_STATUS, val) != NPU_MBOX_SUCCESS)\n \t\tret = -EINVAL;\n \n-\tspin_unlock_bh(\u0026npu-\u003ecores[core].lock);\n+\t/* Copy the trailing reply_len bytes of the response. */\n+\tif (!ret \u0026\u0026 reply)\n+\t\tmemcpy(reply, core-\u003ebuf + len - reply_len, reply_len);\n \n-\tdma_unmap_single(npu-\u003edev, dma_addr, size, DMA_BIDIRECTIONAL);\n+\tspin_unlock_bh(\u0026core-\u003elock);\n \n \treturn ret;\n }\n \n+static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,\n+\t\t\t       void *data, int len)\n+{\n+\treturn __airoha_npu_send_msg(npu, func_id, data, len, data, len);\n+}\n+\n static int airoha_npu_load_firmware(struct device *dev, void __iomem *addr,\n \t\t\t\t    const char *fw_name, int fw_max_size)\n {\n@@ -497,9 +522,8 @@ static int airoha_npu_wlan_msg_get(struct airoha_npu *npu, int ifindex,\n \twlan_data-\u003efunc_type = NPU_OP_GET;\n \twlan_data-\u003efunc_id = func_id;\n \n-\terr = airoha_npu_send_msg(npu, NPU_FUNC_WIFI, wlan_data, len);\n-\tif (!err)\n-\t\tmemcpy(data, wlan_data-\u003ed, data_len);\n+\terr = __airoha_npu_send_msg(npu, NPU_FUNC_WIFI, wlan_data, len,\n+\t\t\t\t    data, data_len);\n \tkfree(wlan_data);\n \n \treturn err;\n@@ -770,6 +794,15 @@ static int airoha_npu_probe(struct platform_device *pdev)\n \tif (err)\n \t\treturn err;\n \n+\tfor (i = 0; i \u003c ARRAY_SIZE(npu-\u003ecores); i++) {\n+\t\tstruct airoha_npu_core *core = \u0026npu-\u003ecores[i];\n+\n+\t\tcore-\u003ebuf = dmam_alloc_coherent(dev, AIROHA_NPU_MBOX_SIZE,\n+\t\t\t\t\t\t\u0026core-\u003eaddr, GFP_KERNEL);\n+\t\tif (!core-\u003ebuf)\n+\t\t\treturn -ENOMEM;\n+\t}\n+\n \terr = airoha_npu_run_firmware(dev, base, \u0026res);\n \tif (err)\n \t\treturn dev_err_probe(dev, err, \"failed to run npu firmware\\n\");\ndiff --git a/include/linux/soc/airoha/airoha_offload.h b/include/linux/soc/airoha/airoha_offload.h\nindex 7589fccfeef6d..16a988ad7467c 100644\n--- a/include/linux/soc/airoha/airoha_offload.h\n+++ b/include/linux/soc/airoha/airoha_offload.h\n@@ -173,6 +173,9 @@ struct airoha_npu {\n \t\t/* protect concurrent npu memory accesses */\n \t\tspinlock_t lock;\n \t\tstruct work_struct wdt_work;\n+\t\t/* Coherent bounce buffer for mailbox cmd/rsp */\n+\t\tvoid *buf;\n+\t\tdma_addr_t addr;\n \t} cores[NPU_NUM_CORES];\n \n \tint irqs[NPU_NUM_IRQ];\n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Airoha NPU driver (drivers/net/ethernet/airoha/airoha_npu.c), which is a vendor-specific SoC platform driver. This hardware is not emulated in standard QEMU or virtualized environments, making the code unreachable during fuzzing.",
  "WorthFuzzing": false
}

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

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

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

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

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


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

For your convenience, here is the diff of the changes:
commit ca5bc19e9d633447599edd14ca8f5d9af8f87899
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 9 16:15:52 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index b679bed952de3..c839e0a419aa5 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -23,6 +23,12 @@
 #define NPU_EN7581_FIRMWARE_RV32_MAX_SIZE	0x200000
 #define NPU_EN7581_FIRMWARE_DATA_MAX_SIZE	0x10000
 #define NPU_DUMP_SIZE				512
+/*
+ * Mailbox DMA payload size. Covers sizeof(struct ppe_mbox_data) (28) and
+ * WLAN TLV messages (header + payload); largest in-tree WLAN payload today
+ * is 16 bytes (INODE_TXRX_REG_ADDR). Keep headroom for future commands.
+ */
+#define AIROHA_NPU_MBOX_SIZE			256
 
 #define REG_NPU_LOCAL_SRAM		0x0
 
@@ -160,23 +166,34 @@ struct wlan_mbox_data {
 	DECLARE_FLEX_ARRAY(u8, d);
 };
 
-static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
-			       void *p, int size)
+static int __airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
+				 const void *data, int len, void *reply,
+				 u16 reply_len)
 {
-	u16 core = 0; /* FIXME */
-	u32 val, offset = core << 4;
-	dma_addr_t dma_addr;
+	struct airoha_npu_core *core = &npu->cores[0]; /* FIXME: core */
+	u32 val, offset = 0;
 	int ret;
 
-	dma_addr = dma_map_single(npu->dev, p, size, DMA_BIDIRECTIONAL);
-	ret = dma_mapping_error(npu->dev, dma_addr);
-	if (ret)
-		return ret;
+	if (len > AIROHA_NPU_MBOX_SIZE)
+		return -EINVAL;
+
+	if (reply && reply_len > len)
+		return -EINVAL;
+
+	/*
+	 * Mailbox payloads are bidirectional (CPU request, NPU response).
+	 * On EN7581+MT7996, streaming DMA_BIDIRECTIONAL against the
+	 * caller kzalloc() buffer can leave WLAN_FUNC_GET_WAIT_NPU_VERSION
+	 * reading as 0.0 despite MBOX success. Reuse a probe-time coherent
+	 * bounce buffer under the per-core lock (also used from PPE
+	 * foe_commit under atomic context).
+	 */
+	spin_lock_bh(&core->lock);
 
-	spin_lock_bh(&npu->cores[core].lock);
+	memcpy(core->buf, data, len);
 
-	regmap_write(npu->regmap, REG_CR_MBQ0_CTRL(0) + offset, dma_addr);
-	regmap_write(npu->regmap, REG_CR_MBQ0_CTRL(1) + offset, size);
+	regmap_write(npu->regmap, REG_CR_MBQ0_CTRL(0) + offset, core->addr);
+	regmap_write(npu->regmap, REG_CR_MBQ0_CTRL(1) + offset, len);
 	regmap_read(npu->regmap, REG_CR_MBQ0_CTRL(2) + offset, &val);
 	regmap_write(npu->regmap, REG_CR_MBQ0_CTRL(2) + offset, val + 1);
 	val = FIELD_PREP(MBOX_MSG_FUNC_ID, func_id) | MBOX_MSG_WAIT_RSP;
@@ -189,13 +206,21 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
 	if (!ret && FIELD_GET(MBOX_MSG_STATUS, val) != NPU_MBOX_SUCCESS)
 		ret = -EINVAL;
 
-	spin_unlock_bh(&npu->cores[core].lock);
+	/* Copy the trailing reply_len bytes of the response. */
+	if (!ret && reply)
+		memcpy(reply, core->buf + len - reply_len, reply_len);
 
-	dma_unmap_single(npu->dev, dma_addr, size, DMA_BIDIRECTIONAL);
+	spin_unlock_bh(&core->lock);
 
 	return ret;
 }
 
+static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
+			       void *data, int len)
+{
+	return __airoha_npu_send_msg(npu, func_id, data, len, data, len);
+}
+
 static int airoha_npu_load_firmware(struct device *dev, void __iomem *addr,
 				    const char *fw_name, int fw_max_size)
 {
@@ -497,9 +522,8 @@ static int airoha_npu_wlan_msg_get(struct airoha_npu *npu, int ifindex,
 	wlan_data->func_type = NPU_OP_GET;
 	wlan_data->func_id = func_id;
 
-	err = airoha_npu_send_msg(npu, NPU_FUNC_WIFI, wlan_data, len);
-	if (!err)
-		memcpy(data, wlan_data->d, data_len);
+	err = __airoha_npu_send_msg(npu, NPU_FUNC_WIFI, wlan_data, len,
+				    data, data_len);
 	kfree(wlan_data);
 
 	return err;
@@ -770,6 +794,15 @@ static int airoha_npu_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	for (i = 0; i < ARRAY_SIZE(npu->cores); i++) {
+		struct airoha_npu_core *core = &npu->cores[i];
+
+		core->buf = dmam_alloc_coherent(dev, AIROHA_NPU_MBOX_SIZE,
+						&core->addr, GFP_KERNEL);
+		if (!core->buf)
+			return -ENOMEM;
+	}
+
 	err = airoha_npu_run_firmware(dev, base, &res);
 	if (err)
 		return dev_err_probe(dev, err, "failed to run npu firmware\n");
diff --git a/include/linux/soc/airoha/airoha_offload.h b/include/linux/soc/airoha/airoha_offload.h
index 7589fccfeef6d..16a988ad7467c 100644
--- a/include/linux/soc/airoha/airoha_offload.h
+++ b/include/linux/soc/airoha/airoha_offload.h
@@ -173,6 +173,9 @@ struct airoha_npu {
 		/* protect concurrent npu memory accesses */
 		spinlock_t lock;
 		struct work_struct wdt_work;
+		/* Coherent bounce buffer for mailbox cmd/rsp */
+		void *buf;
+		dma_addr_t addr;
 	} cores[NPU_NUM_CORES];
 
 	int irqs[NPU_NUM_IRQ];

gemini-3.1-pro-preview

null

null

							input: 3833
							output: 37
							thoughts: 187
						

**Analyzing the Airoha NPU Mailbox Patch**

Okay, so I'm looking at this patch for `drivers/net/ethernet/airoha/airoha_npu.c`. It seems they've switched up the message sending process to the Network Processing Unit (NPU) via the mailbox. Instead of relying on a caller-provided buffer and `dma_map_single` with `DMA_BIDIRECTIONAL`, they're now allocating a coherent DMA buffer during the device probe using `dmam_alloc_coherent`. Then, the data is copied to and from that coherent buffer in `__airoha_npu_send_msg`. Interesting.

The motivation here is a streaming DMA problem on EN7581 with MT7996 – where the data gets zeroed out even though the mailbox communication is supposedly successful. That's a classic DMA coherence issue, so this approach makes sense as a potential fix. It also indicates they think this is a platform specific problem, as it does not affect all platforms.

Now, the question is, how reachable is this code path, and is this change something we might want to target for fuzzing? Let's check the Kconfig and see if we can get a better understanding of the preconditions for this code path.

{
  "Expression": "airoha_npu.o",
  "PathPrefix": "drivers/net/ethernet/airoha/"
}

{
  "Output": "drivers/net/ethernet/airoha/Makefile=8=airoha-eth-$(CONFIG_DEBUG_FS) += airoha_ppe_debugfs.o\ndrivers/net/ethernet/airoha/Makefile:9:obj-$(CONFIG_NET_AIROHA_NPU) += airoha_npu.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 4418
							output: 39
							thoughts: 17
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**Decoding the `CONFIG_NET_AIROHA_NPU` Flag**

Right, so I'm looking at this configuration. The key here is the `CONFIG_NET_AIROHA_NPU` directive. That immediately tells me this involves a configuration flag related to, specifically, an Airoha Network Processing Unit, or NPU. It's a pretty straightforward naming convention; the "NET" suggests the networking context.

My immediate follow up questions would center around:

*   **What specific networking functionality is being enabled or disabled?** Is this related to offloading packet processing, hardware acceleration, security features, or something else entirely? Airoha is a fairly large player in the SoC space, so I'd need to narrow down the target application.
*   **What are the dependencies?** Does this configuration option have downstream impacts on other drivers, modules, or core networking components? I'd check for conditional dependencies to understand its full scope.
*   **What is the default state and why?** Is this a default-enabled feature or something that requires explicit activation? And if it's disabled by default, I would be very interested to understand the rationale and reasons for disabling.
*   **What version of the Airoha NPU?** There are sometimes multiple versions of the same chipset. This can greatly change the behavior of the software and hardware.
*   **Is this a kernel-level configuration?** Or is this within a user-space utility that's related to the NPU? This helps with understanding what tools are needed to actually configure and use this.

Essentially, seeing this flag, my thought process is all about *context*. I need more details to understand the implications of this configuration setting in relation to the broader network infrastructure. It's a starting point, but a starting point that sparks a series of targeted inquiries and investigations.

{
  "Expression": "config NET_AIROHA_NPU",
  "PathPrefix": "drivers/net/ethernet/airoha/"
}

{
  "Output": "drivers/net/ethernet/airoha/Kconfig=8=if NET_VENDOR_AIROHA\ndrivers/net/ethernet/airoha/Kconfig-9-\ndrivers/net/ethernet/airoha/Kconfig:10:config NET_AIROHA_NPU\ndrivers/net/ethernet/airoha/Kconfig-11-\ttristate \"Airoha NPU support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 5001
							output: 38
							thoughts: 18
						

Here's my analysis of what I'm thinking about, presented as you requested:

**Deconstructing Dependencies of NET_AIROHA_NPU**

Okay, so I need to understand the dependencies of `NET_AIROHA_NPU`. I'm going to start by tracing those linkages. My immediate instinct is to think about the layers involved. What other modules, libraries, or hardware components does it rely on to function correctly? Is it a hardware abstraction layer (HAL) for a specific NPU? Or perhaps an intermediary driver? I need to know where it fits into the broader software stack. I also need to understand if it has external dependencies, and what those are. I'll need to drill down into those. Are there specific kernel modules involved, or libraries required to be loaded? Understanding these dependencies is crucial for debugging, porting, or even just optimizing the system. It will also help identify potential areas of conflict with other systems.

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

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\tconfig NET_VENDOR_AIROHA\n   3:\t\tbool \"Airoha devices\"\n   4:\t\tdepends on ARCH_AIROHA || COMPILE_TEST\n   5:\t\thelp\n   6:\t\t  If you have a Airoha SoC with ethernet, say Y.\n   7:\t\n   8:\tif NET_VENDOR_AIROHA\n   9:\t\n  10:\tconfig NET_AIROHA_NPU\n  11:\t\ttristate \"Airoha NPU support\"\n  12:\t\tselect WANT_DEV_COREDUMP\n  13:\t\tselect REGMAP_MMIO\n  14:\t\thelp\n  15:\t\t  This driver supports Airoha Network Processor (NPU) available\n  16:\t\t  on the Airoha Soc family.\n  17:\t\n  18:\tconfig NET_AIROHA\n  19:\t\ttristate \"Airoha SoC Gigabit Ethernet support\"\n  20:\t\tdepends on NET_DSA || !NET_DSA\n"
}

gemini-3.1-pro-preview

null

null

							input: 5532
							output: 37
							thoughts: 337
						

**Analyzing the Airoha NPU Driver for Fuzzing Potential**

Okay, so this code's dependencies are a bit convoluted – it hinges on `NET_VENDOR_AIROHA`, which in turn relies on either `ARCH_AIROHA` or `COMPILE_TEST`. My immediate thought is, can this code path *even* be hit when running in QEMU? I have to be sure it's relevant in a virtual environment.

Let's see, it's an NPU driver (`airoha_npu.c`) intended for Airoha SoCs. It registers itself as a platform driver. Ah, so this is likely a physical hardware driver, meaning it deals with register mapping, firmware loading, and things of that nature. The question then becomes, can we even *fuzz* it?

If it's a platform driver, syzkaller could, theoretically, instantiate a pseudo-device using `syz_dev_create` or something similar, *if* there's a trigger. Platform devices are often Device Tree instantiated, so that's something to investigate. Syzkaller is pretty versatile though, so it might be able to create the DT node if supported. But hardware-specific platform drivers, like NPUs or Ethernet MACs *on* a specific SoC, they're typically not easily fuzzed unless they expose a generic interface or if we can inject the platform device.

Hold on a second, let me re-read these instructions... Aha! The instructions explicitly say to return `WorthFuzzing=false` if the patch involves vendor-specific PCIe switch, SmartNIC, or GPU drivers that require physical PCIe hardware not emulated in standard QEMU. Given what I'm seeing this Airoha NPU driver *is* a platform driver for a specific SoC. It seems very similar to the example drivers listed.

So, the critical question is, does it expose *any* user-space interfaces at all? Or is it purely an internal kernel API? That will determine if this patch is worthy of attention.

{
  "Expression": "airoha_npu_probe",
  "PathPrefix": "drivers/net/ethernet/airoha/"
}

{
  "Output": "drivers/net/ethernet/airoha/airoha_npu.c=709=static const struct regmap_config regmap_config = {\n--\ndrivers/net/ethernet/airoha/airoha_npu.c-716-\ndrivers/net/ethernet/airoha/airoha_npu.c:717:static int airoha_npu_probe(struct platform_device *pdev)\ndrivers/net/ethernet/airoha/airoha_npu.c-718-{\n--\ndrivers/net/ethernet/airoha/airoha_npu.c=846=static struct platform_driver airoha_npu_driver = {\ndrivers/net/ethernet/airoha/airoha_npu.c:847:\t.probe = airoha_npu_probe,\ndrivers/net/ethernet/airoha/airoha_npu.c-848-\t.remove = airoha_npu_remove,\n"
}

gemini-3.1-pro-preview

null

null

							input: 6591
							output: 46
							thoughts: 16
						

Okay, let's dive into this `airoha_npu_probe` function. I need to understand its role. What exactly is this probe doing within the larger system? I'm assuming it's related to the AI acceleration hardware, probably an NPU, since that's what the name suggests. I need to figure out how it's interacting with the overall driver framework. Is it initializing the hardware? Registering interrupt handlers? Probing for the device and its capabilities? I'm especially interested in the error handling. What happens if the probe fails? Does it gracefully fallback, or does it bring down the whole system? I need to understand the implications for overall system stability and performance if this probe goes sideways. Knowing the details will allow me to assess any potential integration issues or optimization opportunities. Time to start digging!

{
  "File": "drivers/net/ethernet/airoha/airoha_npu.c",
  "FirstLine": 717,
  "LineCount": 100
}

{
  "Contents": " 717:\tstatic int airoha_npu_probe(struct platform_device *pdev)\n 718:\t{\n 719:\t\tstruct device *dev = \u0026pdev-\u003edev;\n 720:\t\tstruct airoha_npu *npu;\n 721:\t\tstruct resource res;\n 722:\t\tvoid __iomem *base;\n 723:\t\tint i, irq, err;\n 724:\t\tu32 val;\n 725:\t\n 726:\t\tbase = devm_platform_ioremap_resource(pdev, 0);\n 727:\t\tif (IS_ERR(base))\n 728:\t\t\treturn PTR_ERR(base);\n 729:\t\n 730:\t\tnpu = devm_kzalloc(dev, sizeof(*npu), GFP_KERNEL);\n 731:\t\tif (!npu)\n 732:\t\t\treturn -ENOMEM;\n 733:\t\n 734:\t\tnpu-\u003edev = dev;\n 735:\t\tnpu-\u003eops.ppe_init = airoha_npu_ppe_init;\n 736:\t\tnpu-\u003eops.ppe_deinit = airoha_npu_ppe_deinit;\n 737:\t\tnpu-\u003eops.ppe_init_stats = airoha_npu_ppe_stats_setup;\n 738:\t\tnpu-\u003eops.ppe_flush_sram_entries = airoha_npu_ppe_flush_sram_entries;\n 739:\t\tnpu-\u003eops.ppe_foe_commit_entry = airoha_npu_foe_commit_entry;\n 740:\t\tnpu-\u003eops.wlan_init_reserved_memory = airoha_npu_wlan_init_memory;\n 741:\t\tnpu-\u003eops.wlan_send_msg = airoha_npu_wlan_msg_send;\n 742:\t\tnpu-\u003eops.wlan_get_msg = airoha_npu_wlan_msg_get;\n 743:\t\tnpu-\u003eops.wlan_get_queue_addr = airoha_npu_wlan_queue_addr_get;\n 744:\t\tnpu-\u003eops.wlan_set_irq_status = airoha_npu_wlan_irq_status_set;\n 745:\t\tnpu-\u003eops.wlan_get_irq_status = airoha_npu_wlan_irq_status_get;\n 746:\t\tnpu-\u003eops.wlan_enable_irq = airoha_npu_wlan_irq_enable;\n 747:\t\tnpu-\u003eops.wlan_disable_irq = airoha_npu_wlan_irq_disable;\n 748:\t\n 749:\t\tnpu-\u003eregmap = devm_regmap_init_mmio(dev, base, \u0026regmap_config);\n 750:\t\tif (IS_ERR(npu-\u003eregmap))\n 751:\t\t\treturn PTR_ERR(npu-\u003eregmap);\n 752:\t\n 753:\t\terr = of_reserved_mem_region_to_resource(dev-\u003eof_node, 0, \u0026res);\n 754:\t\tif (err)\n 755:\t\t\treturn err;\n 756:\t\n 757:\t\tirq = platform_get_irq(pdev, 0);\n 758:\t\tif (irq \u003c 0)\n 759:\t\t\treturn irq;\n 760:\t\n 761:\t\terr = devm_request_irq(dev, irq, airoha_npu_mbox_handler,\n 762:\t\t\t\t       IRQF_SHARED, \"airoha-npu-mbox\", npu);\n 763:\t\tif (err)\n 764:\t\t\treturn err;\n 765:\t\n 766:\t\tfor (i = 0; i \u003c ARRAY_SIZE(npu-\u003ecores); i++) {\n 767:\t\t\tstruct airoha_npu_core *core = \u0026npu-\u003ecores[i];\n 768:\t\n 769:\t\t\tspin_lock_init(\u0026core-\u003elock);\n 770:\t\t\tcore-\u003enpu = npu;\n 771:\t\n 772:\t\t\tirq = platform_get_irq(pdev, i + 1);\n 773:\t\t\tif (irq \u003c 0)\n 774:\t\t\t\treturn irq;\n 775:\t\n 776:\t\t\terr = devm_request_irq(dev, irq, airoha_npu_wdt_handler,\n 777:\t\t\t\t\t       IRQF_SHARED, \"airoha-npu-wdt\", core);\n 778:\t\t\tif (err)\n 779:\t\t\t\treturn err;\n 780:\t\n 781:\t\t\tINIT_WORK(\u0026core-\u003ewdt_work, airoha_npu_wdt_work);\n 782:\t\t}\n 783:\t\n 784:\t\t/* wlan IRQ lines */\n 785:\t\tfor (i = 0; i \u003c ARRAY_SIZE(npu-\u003eirqs); i++) {\n 786:\t\t\tirq = platform_get_irq(pdev, i + ARRAY_SIZE(npu-\u003ecores) + 1);\n 787:\t\t\tif (irq \u003c 0)\n 788:\t\t\t\treturn irq;\n 789:\t\n 790:\t\t\tnpu-\u003eirqs[i] = irq;\n 791:\t\t}\n 792:\t\n 793:\t\terr = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));\n 794:\t\tif (err)\n 795:\t\t\treturn err;\n 796:\t\n 797:\t\tfor (i = 0; i \u003c ARRAY_SIZE(npu-\u003ecores); i++) {\n 798:\t\t\tstruct airoha_npu_core *core = \u0026npu-\u003ecores[i];\n 799:\t\n 800:\t\t\tcore-\u003ebuf = dmam_alloc_coherent(dev, AIROHA_NPU_MBOX_SIZE,\n 801:\t\t\t\t\t\t\t\u0026core-\u003eaddr, GFP_KERNEL);\n 802:\t\t\tif (!core-\u003ebuf)\n 803:\t\t\t\treturn -ENOMEM;\n 804:\t\t}\n 805:\t\n 806:\t\terr = airoha_npu_run_firmware(dev, base, \u0026res);\n 807:\t\tif (err)\n 808:\t\t\treturn dev_err_probe(dev, err, \"failed to run npu firmware\\n\");\n 809:\t\n 810:\t\tregmap_write(npu-\u003eregmap, REG_CR_NPU_MIB(10),\n 811:\t\t\t     res.start + NPU_EN7581_FIRMWARE_RV32_MAX_SIZE);\n 812:\t\tregmap_write(npu-\u003eregmap, REG_CR_NPU_MIB(11), 0x40000); /* SRAM 256K */\n 813:\t\tregmap_write(npu-\u003eregmap, REG_CR_NPU_MIB(12), 0);\n 814:\t\tregmap_write(npu-\u003eregmap, REG_CR_NPU_MIB(21), 1);\n 815:\t\tmsleep(100);\n 816:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 8748
							output: 24
							thoughts: 180
						

**Analyzing the Airoha NPU Driver and its Feasibility in QEMU**

Okay, so I'm digging into this driver, and immediately I see it's Device Tree-dependent. It's using `of_reserved_mem_region_to_resource` and grabbing IRQs with `platform_get_irq`, which means we're firmly in DT land. And it's loading firmware using `airoha_npu_run_firmware`, which, I'm assuming, is writing directly to registers and waiting for the Neural Processing Unit to kick on. Right, so the question is, can I even *touch* this thing in QEMU?

Based on the initial information, probably not, it looks like it is a very specific SoC driver, the Airoha EN7581. QEMU definitely wouldn't have built-in emulation for that particular NPU architecture.

But then again, syzkaller *could* potentially get us there. If we could inject a platform device using `syz_dev_create` or something similar, maybe we could trick it. The catch, of course, is that we'd have to mock the memory-mapped I/O, which is rarely done for random SoCs unless there's a dedicated syzkaller description. 

So the next step is pretty obvious: let me check if there's *any* syzkaller description, a dedicated one, for this driver. That would be the silver bullet here.

no matches

{
  "Expression": "airoha",
  "PathPrefix": "sys/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 9285
							output: 94
							thoughts: 148
						

**Airoha NPU Driver - Not Fuzzable with Current Resources**

Okay, let's see. No existing syzkaller description for Airoha, which isn't a great sign to begin with. Then, I remember the instruction: "Return WorthFuzzing=false if the patch only contains... vendor-specific PCIe switch, SmartNIC, or GPU drivers... that require physical PCIe hardware cards not emulated in standard QEMU."

Ah, right. This Airoha NPU driver *definitely* falls into that category. It’s a vendor-specific NPU driver, and those things always need very specific hardware or very specific SoC emulation, which we *don't* have in a typical QEMU setup, or, I'm assuming, something like GCE. Thus, it is not reachable in virtualized environments. 

Therefore, based on my understanding of the system, it's a no-go for fuzzing right now. I’m marking this as `WorthFuzzing=false`.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Airoha NPU driver (drivers/net/ethernet/airoha/airoha_npu.c), which is a vendor-specific SoC platform driver. This hardware is not emulated in standard QEMU or virtualized environments, making the code unreachable during fuzzing.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Airoha NPU driver (drivers/net/ethernet/airoha/airoha_npu.c), which is a vendor-specific SoC platform driver. This hardware is not emulated in standard QEMU or virtualized environments, making the code unreachable during fuzzing.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null