AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch adds PCI reset quirks for specific Qualcomm WLAN and modem devices (vendor ID 0x17cb, device IDs 0x0308, 0x1103, 0x1107). These functions are only executed if the physical hardware is present on the PCI bus. Since these specific devices are not emulated by standard virtualized environments (like QEMU or GCE) and there is no generic software PCI device emulator in the kernel to spoof them, these code paths are unreachable during fuzzing.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 40e482adf9128992f05a2da9b75cf95871164a71\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jun 30 08:55:09 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c\nindex 431c021d7414d2..1633f294ba16d9 100644\n--- a/drivers/pci/quirks.c\n+++ b/drivers/pci/quirks.c\n@@ -4240,6 +4240,120 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)\n \treturn 0;\n }\n \n+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET\t0x3008\n+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V\tBIT(0)\n+#define QUALCOMM_WLAN_MHICTRL\t\t\t0x38\n+#define QUALCOMM_WLAN_MHICTRL_RESET_MASK\t0x2\n+\n+/*\n+ * Qualcomm WLAN device-specific reset using SoC global reset via BAR0\n+ * registers.\n+ */\n+static int reset_qualcomm_wlan(struct pci_dev *pdev, bool probe)\n+{\n+\tbool link_recovered = false;\n+\tunsigned long timeout;\n+\tvoid __iomem *bar;\n+\tu32 val;\n+\tu16 cmd;\n+\n+\tif (probe)\n+\t\treturn 0;\n+\n+\tif (pdev-\u003ecurrent_state != PCI_D0)\n+\t\treturn -EINVAL;\n+\n+\tpci_read_config_word(pdev, PCI_COMMAND, \u0026cmd);\n+\tpci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);\n+\n+\tbar = pci_iomap(pdev, 0, 0);\n+\tif (!bar) {\n+\t\tpci_write_config_word(pdev, PCI_COMMAND, cmd);\n+\t\treturn -ENODEV;\n+\t}\n+\n+\tval = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);\n+\tval |= QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;\n+\tiowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);\n+\tioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);\n+\n+\tmsleep(10);\n+\n+\tval \u0026= ~QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;\n+\tiowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);\n+\tioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);\n+\n+\tmsleep(10);\n+\n+\ttimeout = jiffies + msecs_to_jiffies(5000);\n+\twhile (time_before(jiffies, timeout)) {\n+\t\tval = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);\n+\t\tif (!PCI_POSSIBLE_ERROR(val)) {\n+\t\t\tlink_recovered = true;\n+\t\t\tbreak;\n+\t\t}\n+\t\tmsleep(20);\n+\t}\n+\n+\tif (!link_recovered) {\n+\t\tpci_err(pdev, \"PCIe link failed to recover after reset\\n\");\n+\t\tgoto out_restore;\n+\t}\n+\n+\t/* After SOC_GLOBAL_RESET, MHISTATUS may still have SYSERR bit set\n+\t * and thus need to set MHICTRL_RESET to clear SYSERR.\n+\t */\n+\tiowrite32(QUALCOMM_WLAN_MHICTRL_RESET_MASK, bar + QUALCOMM_WLAN_MHICTRL);\n+\tioread32(bar + QUALCOMM_WLAN_MHICTRL);\n+\n+\tmsleep(10);\n+\n+out_restore:\n+\tpci_iounmap(pdev, bar);\n+\tpci_write_config_word(pdev, PCI_COMMAND, cmd);\n+\n+\treturn link_recovered ? 0 : -ETIMEDOUT;\n+}\n+\n+#define MHI_SOC_RESET_REQ_OFFSET\t\t0xb0\n+#define MHI_SOC_RESET_REQ\t\t\tBIT(0)\n+\n+/*\n+ * Qualcomm modem device-specific reset using MHI SoC reset via BAR0\n+ * register.\n+ */\n+static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)\n+{\n+\tvoid __iomem *bar;\n+\tu16 cmd;\n+\n+\tif (probe)\n+\t\treturn 0;\n+\n+\tif (pdev-\u003ecurrent_state != PCI_D0)\n+\t\treturn -EINVAL;\n+\n+\tpci_read_config_word(pdev, PCI_COMMAND, \u0026cmd);\n+\tpci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);\n+\n+\tbar = pci_iomap(pdev, 0, 0);\n+\tif (!bar) {\n+\t\tpci_write_config_word(pdev, PCI_COMMAND, cmd);\n+\t\treturn -ENODEV;\n+\t}\n+\n+\tiowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);\n+\tioread32(bar + MHI_SOC_RESET_REQ_OFFSET);\n+\n+\t/* Be sure device reset has been executed */\n+\tmsleep(2000);\n+\n+\tpci_iounmap(pdev, bar);\n+\tpci_write_config_word(pdev, PCI_COMMAND, cmd);\n+\n+\treturn 0;\n+}\n+\n static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {\n \t{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,\n \t\t reset_intel_82599_sfp_virtfn },\n@@ -4255,6 +4369,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {\n \t\treset_chelsio_generic_dev },\n \t{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,\n \t\treset_hinic_vf_dev },\n+\t{ PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */\n+\t{ PCI_VENDOR_ID_QCOM, 0x1103, reset_qualcomm_wlan },  /* WCN6855 WLAN */\n+\t{ PCI_VENDOR_ID_QCOM, 0x1107, reset_qualcomm_wlan },  /* WCN7850 WLAN */\n \t{ 0 }\n };\n \n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch adds PCI reset quirks for specific Qualcomm WLAN and modem devices (vendor ID 0x17cb, device IDs 0x0308, 0x1103, 0x1107). These functions are only executed if the physical hardware is present on the PCI bus. Since these specific devices are not emulated by standard virtualized environments (like QEMU or GCE) and there is no generic software PCI device emulator in the kernel to spoof them, these code paths are 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).

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.
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.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. 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 40e482adf9128992f05a2da9b75cf95871164a71
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jun 30 08:55:09 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 431c021d7414d2..1633f294ba16d9 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4240,6 +4240,120 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }
 
+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET	0x3008
+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V	BIT(0)
+#define QUALCOMM_WLAN_MHICTRL			0x38
+#define QUALCOMM_WLAN_MHICTRL_RESET_MASK	0x2
+
+/*
+ * Qualcomm WLAN device-specific reset using SoC global reset via BAR0
+ * registers.
+ */
+static int reset_qualcomm_wlan(struct pci_dev *pdev, bool probe)
+{
+	bool link_recovered = false;
+	unsigned long timeout;
+	void __iomem *bar;
+	u32 val;
+	u16 cmd;
+
+	if (probe)
+		return 0;
+
+	if (pdev->current_state != PCI_D0)
+		return -EINVAL;
+
+	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+	bar = pci_iomap(pdev, 0, 0);
+	if (!bar) {
+		pci_write_config_word(pdev, PCI_COMMAND, cmd);
+		return -ENODEV;
+	}
+
+	val = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	val |= QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;
+	iowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+
+	msleep(10);
+
+	val &= ~QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;
+	iowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+
+	msleep(10);
+
+	timeout = jiffies + msecs_to_jiffies(5000);
+	while (time_before(jiffies, timeout)) {
+		val = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+		if (!PCI_POSSIBLE_ERROR(val)) {
+			link_recovered = true;
+			break;
+		}
+		msleep(20);
+	}
+
+	if (!link_recovered) {
+		pci_err(pdev, "PCIe link failed to recover after reset\n");
+		goto out_restore;
+	}
+
+	/* After SOC_GLOBAL_RESET, MHISTATUS may still have SYSERR bit set
+	 * and thus need to set MHICTRL_RESET to clear SYSERR.
+	 */
+	iowrite32(QUALCOMM_WLAN_MHICTRL_RESET_MASK, bar + QUALCOMM_WLAN_MHICTRL);
+	ioread32(bar + QUALCOMM_WLAN_MHICTRL);
+
+	msleep(10);
+
+out_restore:
+	pci_iounmap(pdev, bar);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+	return link_recovered ? 0 : -ETIMEDOUT;
+}
+
+#define MHI_SOC_RESET_REQ_OFFSET		0xb0
+#define MHI_SOC_RESET_REQ			BIT(0)
+
+/*
+ * Qualcomm modem device-specific reset using MHI SoC reset via BAR0
+ * register.
+ */
+static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
+{
+	void __iomem *bar;
+	u16 cmd;
+
+	if (probe)
+		return 0;
+
+	if (pdev->current_state != PCI_D0)
+		return -EINVAL;
+
+	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+	bar = pci_iomap(pdev, 0, 0);
+	if (!bar) {
+		pci_write_config_word(pdev, PCI_COMMAND, cmd);
+		return -ENODEV;
+	}
+
+	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
+	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
+
+	/* Be sure device reset has been executed */
+	msleep(2000);
+
+	pci_iounmap(pdev, bar);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+	return 0;
+}
+
 static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
 		 reset_intel_82599_sfp_virtfn },
@@ -4255,6 +4369,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 		reset_chelsio_generic_dev },
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
+	{ PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */
+	{ PCI_VENDOR_ID_QCOM, 0x1103, reset_qualcomm_wlan },  /* WCN6855 WLAN */
+	{ PCI_VENDOR_ID_QCOM, 0x1107, reset_qualcomm_wlan },  /* WCN7850 WLAN */
 	{ 0 }
 };
 

gemini-3.1-pro-preview

null

null

							input: 3350
							output: 29
							thoughts: 270
						

**Analyzing a PCI Quirks Patch**

Okay, so there's a patch introducing two new functions, `reset_qualcomm_wlan` and `reset_qualcomm_modem`, within `drivers/pci/quirks.c`. These are getting added to the `pci_dev_reset_methods` array, which immediately flags it as a potential area for fuzzing. This patch is modifying PCI quirks, which means it's executed during the initialization or reset of PCI devices. The question now is: how easily can I reach this in a virtualized environment?

My first thought is, if we emulate a PCI device with the right vendor and device ID, then *maybe* it's reachable. Then I remember that syzkaller *can* emulate PCI devices using vhci or similar mechanisms, like the `syz_pci_device` calls, right? The tool does offer some support for PCI device emulation, but I know PCI quirks are often tightly coupled with specific hardware.

But wait, syzkaller *does* have a PCI fuzzer, like `syz_pci_device_add`! Now I'm on the right track. Let's dig deeper. The next step is to figure out whether `drivers/pci/quirks.c` is compiled by default or if specific configurations are needed. Quick check... it's conditional, compiled only if `CONFIG_PCI_QUIRKS` is enabled. Time to check the `drivers/pci/Makefile` to confirm the details.

{
  "Expression": "quirks.o",
  "PathPrefix": "drivers/pci/"
}

{
  "Output": "drivers/pci/Makefile=21=obj-$(CONFIG_OF)\t\t+= of.o\ndrivers/pci/Makefile:22:obj-$(CONFIG_PCI_QUIRKS)\t+= quirks.o\ndrivers/pci/Makefile-23-obj-$(CONFIG_HOTPLUG_PCI)\t+= hotplug/\n"
}

gemini-3.1-pro-preview

null

null

							input: 4064
							output: 31
							thoughts: 19
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating `CONFIG_PCI_QUIRKS` Default State**

Right, let's just confirm something quickly. I need to make sure I understand the default configuration of the kernel in relation to PCI quirks. The specific detail I'm looking for is whether or not `CONFIG_PCI_QUIRKS` is enabled out-of-the-box. This is important because it sets the baseline for understanding the system's behavior, and how much modification I might need to make to accommodate certain hardware oddities. I want to confirm whether I need to explicitly enable quirks or if they are already active. Knowing the default gives me a crucial starting point for any diagnostic or configuration work. So, let's go check the relevant Kconfig file or configuration tool and find out definitively.

{
  "Expression": "config PCI_QUIRKS",
  "PathPrefix": "drivers/pci/"
}

{
  "Output": "drivers/pci/Kconfig=59=config PCI_MSI_ARCH_FALLBACKS\n--\ndrivers/pci/Kconfig-61-\ndrivers/pci/Kconfig:62:config PCI_QUIRKS\ndrivers/pci/Kconfig-63-\tdefault y\n"
}

gemini-3.1-pro-preview

null

null

							input: 4377
							output: 37
							thoughts: 72
						

**Analyzing PCI Device Reset Methods**

Okay, so the system's default behavior leans toward assuming a "yes" response, which means `drivers/pci/quirks.c` gets compiled. That’s the first piece of the puzzle. Now, I see that within that file, the functions `reset_qualcomm_wlan` and `reset_qualcomm_modem` are being added to the `pci_dev_reset_methods` structure. This immediately raises a question in my mind: where is `pci_dev_reset_methods` actually *used*? That's the crucial link I need to understand the practical implications of these additions. Without knowing where this structure is utilized, I can't determine the scope or effect of these Qualcomm-specific reset functions. I need to trace the usage of this variable to see how it interacts with the broader PCI device reset mechanism.

{
  "Expression": "pci_dev_reset_methods",
  "PathPrefix": "drivers/pci/quirks.c"
}

{
  "Output": "drivers/pci/quirks.c=4325=static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)\n--\ndrivers/pci/quirks.c-4356-\ndrivers/pci/quirks.c:4357:static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {\ndrivers/pci/quirks.c-4358-\t{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,\n--\ndrivers/pci/quirks.c=4378=static int __pci_dev_specific_reset(struct pci_dev *dev, bool probe,\ndrivers/pci/quirks.c:4379:\t\t\t\t    const struct pci_dev_reset_methods *i)\ndrivers/pci/quirks.c-4380-{\n--\ndrivers/pci/quirks.c=4399=int pci_dev_specific_reset(struct pci_dev *dev, bool probe)\ndrivers/pci/quirks.c-4400-{\ndrivers/pci/quirks.c:4401:\tconst struct pci_dev_reset_methods *i;\ndrivers/pci/quirks.c-4402-\ndrivers/pci/quirks.c:4403:\tfor (i = pci_dev_reset_methods; i-\u003ereset; i++) {\ndrivers/pci/quirks.c-4404-\t\tif ((i-\u003evendor == dev-\u003evendor ||\n"
}

gemini-3.1-pro-preview

null

null

							input: 5082
							output: 143
							thoughts: 1035
						

**Unreachable Code Path Analysis**

Okay, so I'm looking at `pci_dev_specific_reset`, which is called from functions like `pci_reset_function`. My first thought is, "Can syzkaller trigger this?" I know syzkaller can inject devices, but does it do that for PCI in a generic way? I've used `syz_kvm_setup_cpu` and `syz_pci_device_add` before, but those feel limited. For USB, syzkaller has `syz_usb_connect`, and for HCI, there's `syz_vhci_setup`, but nothing equivalent for PCI jumps out.

I quickly check, and while QEMU can emulate PCI, syzkaller itself doesn't offer a ready-made PCI device emulator like it does for USB. I consider `vfio` or `pci_endpoint_test` as potential avenues. Then I remember userspace *can* trigger PCI resets via sysfs, specifically the `/sys/bus/pci/devices/.../reset` path. If the kernel finds a PCI device with the right vendor/device IDs, this quirk is called.

The critical question is, "Can such a device *exist* in a virtualized environment?". Unless QEMU is specifically configured to emulate this Qualcomm WLAN/Modem device—and it almost certainly isn't—or some software PCI endpoint framework lets us create arbitrary devices, the answer is probably no. I know Linux has some endpoint testing tools like `pci-epf-test`, but those need actual hardware support (PCI endpoint controllers). I investigate `CONFIG_PCI_STUB` and `CONFIG_VFIO_PCI` to see if they offer a workaround.

I search the kernel code for `syz_pci` or similar, hoping for a generic PCI emulator within syzkaller, but find nothing. My thoughts turn to `PCI_VENDOR_ID_QCOM`. Can I reach this specific code without the physical hardware present? If I don't have the hardware, and no emulator, then the code is probably unreachable.

I do a deeper dive, looking at `drivers/misc/dummy-irq.c` and `drivers/pci/controller/pci-host-generic.c`, but nothing seems relevant. Then, the `Documentation/PCI/endpoint/pci-test-howto.rst` catches my eye, particularly the `pci_epf_test` mention. I'm trying to figure out if there's *any* way to get `pci_dev_specific_reset` called without the actual device. But the function needs a `struct pci_dev *dev`, which means the device *must* be on the PCI bus.

Can I fake a PCI device? I explore `drivers/pci/pci-stub.c` (which just binds to existing devices) and `drivers/virtio/virtio_pci.c` (creates virtio devices) and even briefly glance at `drivers/misc/cxl/`, but they don't seem like the solution. I consider `/sys/bus/pci/drivers_dummy/new_id` but that just adds an ID to a driver, not a new device.

Therefore, without the actual Qualcomm WLAN/Modem device, this looks unreachable in a typical virtualized environment (like GCE or standard QEMU setup). So, I verify that QEMU *doesn't* emulate `PCI_VENDOR_ID_QCOM`, which is `0x17cb`. Examining the patch, I confirm the specific vendor/device ID pairs that trigger this quirk: `PCI_VENDOR_ID_QCOM, 0x0308`, `0x1103`, and `0x1107`. QEMU *doesn't* emulate any of these.

Given that these specific Qualcomm devices are not emulated, this code is completely unreachable in my current fuzzing environment. I have to be absolutely sure there's no other path to this, and there isn't, because it's a PCI quirk that *demands* specific vendor/device IDs. If the device isn't there, the quirk doesn't run. Since I have no hardware and no QEMU emulation, the result is that the code is unreachable. I'll return WorthFuzzing=false.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch adds PCI reset quirks for specific Qualcomm WLAN and modem devices (vendor ID 0x17cb, device IDs 0x0308, 0x1103, 0x1107). These functions are only executed if the physical hardware is present on the PCI bus. Since these specific devices are not emulated by standard virtualized environments (like QEMU or GCE) and there is no generic software PCI device emulator in the kernel to spoof them, these code paths are unreachable during fuzzing.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch adds PCI reset quirks for specific Qualcomm WLAN and modem devices (vendor ID 0x17cb, device IDs 0x0308, 0x1103, 0x1107). These functions are only executed if the physical hardware is present on the PCI bus. Since these specific devices are not emulated by standard virtualized environments (like QEMU or GCE) and there is no generic software PCI device emulator in the kernel to spoof them, these code paths are unreachable during fuzzing.",
  "WorthFuzzing": false
}