AI Trajectory


Trajectory: (Expand/Collapse All)
Seq Timestamp Type Name Duration
0/0 2026/09/17 02:51 flow patch-triage
0m Args: 
null

Results: 
{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the Intel NPU (ivpu) driver under drivers/accel/ivpu/. This driver requires physical Intel NPU hardware (found on Meteor Lake and newer Intel CPUs) connected via PCIe, which is not emulated in standard QEMU or cloud VM environments. As a result, the driver cannot probe and the modified code paths are structurally unreachable for syzkaller fuzzing.",
  "WorthFuzzing": false
}
1/1 2026/09/17 02:51 action read-patch-diff
0m Args: 
null

Results: 
{
  "PatchDiff": "commit 28098c7f124533b53af61969f303b434a4111b11\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Thu Sep 17 02:51:24 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c\nindex 95120957f42a5..8c1c87e69f91f 100644\n--- a/drivers/accel/ivpu/ivpu_drv.c\n+++ b/drivers/accel/ivpu/ivpu_drv.c\n@@ -515,6 +515,7 @@ void ivpu_prepare_for_reset(struct ivpu_device *vdev)\n {\n \tivpu_hw_irq_disable(vdev);\n \tdisable_irq(vdev-\u003eirq);\n+\tatomic_set(\u0026vdev-\u003ejob_timeout_detected, 0);\n \tflush_work(\u0026vdev-\u003eirq_dct_work);\n \tflush_work(\u0026vdev-\u003econtext_abort_work);\n \tflush_work(\u0026vdev-\u003ejob_destroy_work);\n@@ -710,7 +711,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)\n \tvdev-\u003econtext_xa_limit.max = IVPU_USER_CONTEXT_MAX_SSID;\n \tatomic64_set(\u0026vdev-\u003eunique_id_counter, 0);\n \tatomic_set(\u0026vdev-\u003ejob_timeout_counter, 0);\n-\tatomic_set(\u0026vdev-\u003efaults_detected, 0);\n+\tatomic_set(\u0026vdev-\u003ejob_timeout_detected, 0);\n \txa_init_flags(\u0026vdev-\u003econtext_xa, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);\n \txa_init_flags(\u0026vdev-\u003esubmitted_jobs_xa, XA_FLAGS_ALLOC1);\n \txa_init_flags(\u0026vdev-\u003edb_xa, XA_FLAGS_ALLOC1);\ndiff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h\nindex 86d7c9966cacb..6f40129264789 100644\n--- a/drivers/accel/ivpu/ivpu_drv.h\n+++ b/drivers/accel/ivpu/ivpu_drv.h\n@@ -171,7 +171,7 @@ struct ivpu_device {\n \tstruct xarray submitted_jobs_xa;\n \tstruct ivpu_ipc_consumer job_done_consumer;\n \tatomic_t job_timeout_counter;\n-\tatomic_t faults_detected;\n+\tatomic_t job_timeout_detected;\n \n \tatomic64_t unique_id_counter;\n \ndiff --git a/drivers/accel/ivpu/ivpu_job.c b/drivers/accel/ivpu/ivpu_job.c\nindex ebb2c865b09a0..4689b8ab519d7 100644\n--- a/drivers/accel/ivpu/ivpu_job.c\n+++ b/drivers/accel/ivpu/ivpu_job.c\n@@ -621,7 +621,6 @@ bool ivpu_job_handle_engine_error(struct ivpu_device *vdev, u32 job_id, u32 job_\n \t\t * status and ensure both are handled in the same way\n \t\t */\n \t\tjob-\u003efile_priv-\u003ehas_mmu_faults = true;\n-\t\tatomic_set(\u0026vdev-\u003efaults_detected, 1);\n \t\tqueue_work(system_percpu_wq, \u0026vdev-\u003econtext_abort_work);\n \t\treturn true;\n \t}\n@@ -1175,10 +1174,10 @@ static int reset_engine_and_mark_faulty_contexts(struct ivpu_device *vdev)\n \t\treturn ret;\n \n \t/*\n-\t * If faults are detected, ignore guilty contexts from engine reset as NPU may not be stuck\n-\t * and could return currently running good context and faulty contexts are already marked\n+\t * If job timeout is detected, read guilty context from engine reset, for other reasons\n+\t * faulty context is already known\n \t */\n-\tif (atomic_cmpxchg(\u0026vdev-\u003efaults_detected, 1, 0) == 1)\n+\tif (atomic_cmpxchg(\u0026vdev-\u003ejob_timeout_detected, 1, 0) == 0)\n \t\treturn 0;\n \n \tnum_impacted_contexts = resp.payload.engine_reset_done.num_impacted_contexts;\ndiff --git a/drivers/accel/ivpu/ivpu_mmu.c b/drivers/accel/ivpu/ivpu_mmu.c\nindex 41efd8985fa67..b2025274f91de 100644\n--- a/drivers/accel/ivpu/ivpu_mmu.c\n+++ b/drivers/accel/ivpu/ivpu_mmu.c\n@@ -964,7 +964,6 @@ void ivpu_mmu_irq_evtq_handler(struct ivpu_device *vdev)\n \t\tfile_priv = xa_load(\u0026vdev-\u003econtext_xa, ssid);\n \t\tif (file_priv) {\n \t\t\tif (!READ_ONCE(file_priv-\u003ehas_mmu_faults)) {\n-\t\t\t\tatomic_set(\u0026vdev-\u003efaults_detected, 1);\n \t\t\t\tivpu_mmu_dump_event(vdev, event);\n \t\t\t\tWRITE_ONCE(file_priv-\u003ehas_mmu_faults, true);\n \t\t\t}\ndiff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c\nindex c1ce8329790e0..de0becbfdffb2 100644\n--- a/drivers/accel/ivpu/ivpu_pm.c\n+++ b/drivers/accel/ivpu/ivpu_pm.c\n@@ -229,6 +229,7 @@ static void ivpu_job_timeout_work(struct work_struct *work)\n \n \tivpu_jsm_state_dump(vdev);\n \tivpu_dev_coredump(vdev);\n+\tatomic_set(\u0026vdev-\u003ejob_timeout_detected, 1);\n \tqueue_work(system_percpu_wq, \u0026vdev-\u003econtext_abort_work);\n }\n \n"
}
2/1 2026/09/17 02:51 agent patch-evaluator
0m Model: 
core

Args: 
null

Results: 
{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Intel NPU (ivpu) driver under drivers/accel/ivpu/. This driver requires physical Intel NPU hardware (found on Meteor Lake and newer Intel CPUs) connected via PCIe, which is not emulated in standard QEMU or cloud VM environments. As a result, the driver cannot probe and the modified code paths are structurally unreachable for syzkaller fuzzing.",
  "WorthFuzzing": false
}

Instruction: 
You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.

================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.

- REACHABILITY IS THE PRIMARY GATE:
  Fuzzing can only discover bugs in code that can actually execute in standard virtualized
  environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
  If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
  regardless of whether it adds assertions or complex logic.

- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
  Patch authors routinely label changes as "cleanups", "refactorings", or state
  "No functional change intended". Do NOT take these claims at face value.
  Code refactorings that rearrange logic, introduce helper functions, or alter state management
  in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
  If reachable executable code is modified or refactored, it MUST be fuzzed.

- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
  When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
  BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
  Even if the author believes the invariant always holds, fuzzing is essential to verify whether
  an unusual sequence of operations can violate it.

================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:

- Non-kernel and non-executable changes:
  * Modifications to Documentation/, comments, or spelling fixes.
  * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
    that do not affect the compiled kernel image (vmlinux) or kernel modules.
  * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
    that do not alter control flow or data structures.
  * Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
  * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
    ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
  * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
    physical PCI hot-unplug or manual sysfs driver unbinding.
  * Code paths exclusive to architectures other than the target architecture.

================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
  * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
    BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
  * Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
  * Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
  * Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).

================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:

- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
  Do NOT list generic, ubiquitous functions called by almost every program in the corpus
  (including, but not limited to: general memory allocators and deallocators, page fault
  and trap handlers, or core synchronization primitives; this is not an exhaustive list).
  Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
  which severely dilutes fuzzing effort away from the actual changes.

- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
  List functions that specifically implement the logic being added or altered, or direct API entrypoints
  for the subsystem feature under review.

- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
  Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
  distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
  If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
  functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).

================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


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

Prompt: 
Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 28098c7f124533b53af61969f303b434a4111b11
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Sep 17 02:51:24 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 95120957f42a5..8c1c87e69f91f 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -515,6 +515,7 @@ void ivpu_prepare_for_reset(struct ivpu_device *vdev)
 {
 	ivpu_hw_irq_disable(vdev);
 	disable_irq(vdev->irq);
+	atomic_set(&vdev->job_timeout_detected, 0);
 	flush_work(&vdev->irq_dct_work);
 	flush_work(&vdev->context_abort_work);
 	flush_work(&vdev->job_destroy_work);
@@ -710,7 +711,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
 	vdev->context_xa_limit.max = IVPU_USER_CONTEXT_MAX_SSID;
 	atomic64_set(&vdev->unique_id_counter, 0);
 	atomic_set(&vdev->job_timeout_counter, 0);
-	atomic_set(&vdev->faults_detected, 0);
+	atomic_set(&vdev->job_timeout_detected, 0);
 	xa_init_flags(&vdev->context_xa, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
 	xa_init_flags(&vdev->submitted_jobs_xa, XA_FLAGS_ALLOC1);
 	xa_init_flags(&vdev->db_xa, XA_FLAGS_ALLOC1);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 86d7c9966cacb..6f40129264789 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -171,7 +171,7 @@ struct ivpu_device {
 	struct xarray submitted_jobs_xa;
 	struct ivpu_ipc_consumer job_done_consumer;
 	atomic_t job_timeout_counter;
-	atomic_t faults_detected;
+	atomic_t job_timeout_detected;
 
 	atomic64_t unique_id_counter;
 
diff --git a/drivers/accel/ivpu/ivpu_job.c b/drivers/accel/ivpu/ivpu_job.c
index ebb2c865b09a0..4689b8ab519d7 100644
--- a/drivers/accel/ivpu/ivpu_job.c
+++ b/drivers/accel/ivpu/ivpu_job.c
@@ -621,7 +621,6 @@ bool ivpu_job_handle_engine_error(struct ivpu_device *vdev, u32 job_id, u32 job_
 		 * status and ensure both are handled in the same way
 		 */
 		job->file_priv->has_mmu_faults = true;
-		atomic_set(&vdev->faults_detected, 1);
 		queue_work(system_percpu_wq, &vdev->context_abort_work);
 		return true;
 	}
@@ -1175,10 +1174,10 @@ static int reset_engine_and_mark_faulty_contexts(struct ivpu_device *vdev)
 		return ret;
 
 	/*
-	 * If faults are detected, ignore guilty contexts from engine reset as NPU may not be stuck
-	 * and could return currently running good context and faulty contexts are already marked
+	 * If job timeout is detected, read guilty context from engine reset, for other reasons
+	 * faulty context is already known
 	 */
-	if (atomic_cmpxchg(&vdev->faults_detected, 1, 0) == 1)
+	if (atomic_cmpxchg(&vdev->job_timeout_detected, 1, 0) == 0)
 		return 0;
 
 	num_impacted_contexts = resp.payload.engine_reset_done.num_impacted_contexts;
diff --git a/drivers/accel/ivpu/ivpu_mmu.c b/drivers/accel/ivpu/ivpu_mmu.c
index 41efd8985fa67..b2025274f91de 100644
--- a/drivers/accel/ivpu/ivpu_mmu.c
+++ b/drivers/accel/ivpu/ivpu_mmu.c
@@ -964,7 +964,6 @@ void ivpu_mmu_irq_evtq_handler(struct ivpu_device *vdev)
 		file_priv = xa_load(&vdev->context_xa, ssid);
 		if (file_priv) {
 			if (!READ_ONCE(file_priv->has_mmu_faults)) {
-				atomic_set(&vdev->faults_detected, 1);
 				ivpu_mmu_dump_event(vdev, event);
 				WRITE_ONCE(file_priv->has_mmu_faults, true);
 			}
diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c
index c1ce8329790e0..de0becbfdffb2 100644
--- a/drivers/accel/ivpu/ivpu_pm.c
+++ b/drivers/accel/ivpu/ivpu_pm.c
@@ -229,6 +229,7 @@ static void ivpu_job_timeout_work(struct work_struct *work)
 
 	ivpu_jsm_state_dump(vdev);
 	ivpu_dev_coredump(vdev);
+	atomic_set(&vdev->job_timeout_detected, 1);
 	queue_work(system_percpu_wq, &vdev->context_abort_work);
 }

3/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 4278
							output: 35
							thoughts: 147

Thoughts: 
**Analyzing this Patch for Reachability**

Okay, let's dive into this. The first thing I'm doing is noting the files the patch modifies. I see it touches `drivers/accel/ivpu/ivpu_drv.c`, `drivers/accel/ivpu/ivpu_drv.h`, `drivers/accel/ivpu/ivpu_job.c`, `drivers/accel/ivpu/ivpu_mmu.c`, and `drivers/accel/ivpu/ivpu_pm.c`. That tells me this is all related to the `ivpu` driver, which from the file paths, looks like it's within the acceleration subsystem.

Now, a critical step: I need to quickly establish if this `ivpu` driver is even *reachable*. I have to know if it's compiled into the kernel for a particular configuration. I'm immediately thinking "Kconfig". I'll use `read-file` or `grepper` in that `drivers/accel/ivpu/` directory to hunt for the Kconfig entry defining this. That should provide the necessary context to determine the conditions under which this driver is built and, therefore, whether this patch actually matters for any of our targets. This is how I'll establish if the changes are relevant to any of the systems I am supporting.

4/2 2026/09/17 02:51 tool grepper
0m Args: 
{
  "Expression": "config DRM_ACCEL_IVPU",
  "PathPrefix": "drivers/accel/ivpu"
}

Results: 
{
  "Output": "drivers/accel/ivpu/Kconfig-2-\ndrivers/accel/ivpu/Kconfig:3:config DRM_ACCEL_IVPU\ndrivers/accel/ivpu/Kconfig-4-\ttristate \"Intel NPU (Neural Processing Unit)\"\n--\ndrivers/accel/ivpu/Kconfig-19-\ndrivers/accel/ivpu/Kconfig:20:config DRM_ACCEL_IVPU_DEBUG\ndrivers/accel/ivpu/Kconfig-21-\tbool \"Intel NPU debug mode\"\n"
}
5/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 4891
							output: 36
							thoughts: 16

Thoughts: 
Here's my summary, as though I'm reading and processing the `drivers/accel/ivpu/Kconfig` file:

**Diving into the IVPU Kconfig**

Alright, let's get into this `drivers/accel/ivpu/Kconfig` file. First, I'm expecting this to define the configuration options for the Image and Video Processing Unit (IVPU) driver, obviously. So, my initial thought is, what level of control does this offer? Is it a basic enable/disable, or is it granular enough to allow for finer control over specific features or hardware aspects of the IVPU? I need to understand the scope of the customization here.

I'm scanning for the overall structure – what are the top-level menu entries? Are they organized by functionality (e.g., video encoding, image processing, power management), by hardware component, or by something else entirely? A logical structure will make this much easier to navigate and digest. I'm looking for the dependencies – which other Kconfig options does this driver rely on? Are there any hard dependencies on other hardware drivers or kernel subsystems? And conversely, are there any features that are mutually exclusive?

I need to see how the IVPU driver integrates with the rest of the system. Does it have options for different hardware revisions or configurations of the IVPU? Are there any performance tuning parameters that I can tweak? Are there any flags or parameters related to debug functionality or trace options, perhaps for performance profiling? And finally, does it have any options related to features, like power management or error handling.

Crucially, I want to evaluate the clarity and conciseness of the help text. Does it provide sufficient context for each option? Does it clearly explain the implications of enabling or disabling a given feature? A well-written Kconfig file is a joy to work with, while a poorly documented one can be a real headache, especially with complex hardware. I hope the Kconfig's maintainer put some work into it! Ultimately, I'm looking to understand what knobs I can turn to tailor the IVPU driver to my specific needs and hardware configuration.

6/2 2026/09/17 02:51 tool read-file
0m Args: 
{
  "File": "drivers/accel/ivpu/Kconfig",
  "FirstLine": 1,
  "LineCount": 35
}

Results: 
{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t\n   3:\tconfig DRM_ACCEL_IVPU\n   4:\t\ttristate \"Intel NPU (Neural Processing Unit)\"\n   5:\t\tdepends on DRM_ACCEL\n   6:\t\tdepends on X86_64 \u0026\u0026 !UML\n   7:\t\tdepends on PCI \u0026\u0026 PCI_MSI\n   8:\t\tselect FW_LOADER\n   9:\t\tselect DRM_GEM_SHMEM_HELPER\n  10:\t\tselect GENERIC_ALLOCATOR\n  11:\t\tselect WANT_DEV_COREDUMP\n  12:\t\thelp\n  13:\t\t  Choose this option if you have a system with an 14th generation\n  14:\t\t  Intel CPU (Meteor Lake) or newer. Intel NPU (formerly called Intel VPU)\n  15:\t\t  is a CPU-integrated inference accelerator for Computer Vision\n  16:\t\t  and Deep Learning applications.\n  17:\t\n  18:\t\t  If \"M\" is selected, the module will be called intel_vpu.\n  19:\t\n  20:\tconfig DRM_ACCEL_IVPU_DEBUG\n  21:\t\tbool \"Intel NPU debug mode\"\n  22:\t\tdepends on DRM_ACCEL_IVPU\n  23:\t\thelp\n  24:\t\t  Choose this option to enable additional\n  25:\t\t  debug features for the Intel NPU driver:\n  26:\t\t  - Always print debug messages regardless of dyndbg config,\n  27:\t\t  - Enable unsafe module params.\n"
}
7/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 5782
							output: 33
							thoughts: 123

Thoughts: 
**Analyzing the Intel NPU Driver**

Okay, so the `DRM_ACCEL_IVPU` option is for systems with 14th gen Intel CPUs or newer, specifically those with the Intel NPU. They're positioning this as a dedicated inference accelerator, mainly for Computer Vision and Deep Learning. That makes sense, leveraging that integrated hardware for offloading those computationally intensive tasks.

But the text says it depends on PCI and PCI_MSI, which raises a flag. Is this driver talking directly to physical PCI hardware? I need to clarify how this works. Let's dig deeper. The best way to understand this driver is to check how it interfaces with the PCI bus. I'll need to examine `drivers/accel/ivpu/ivpu_drv.c` to see how it registers itself. Does it use the standard PCI driver model? Is it emulated or virtualized, somehow? I need to see if it's directly mapping memory or using another abstraction layer. The source code will tell the story.

8/2 2026/09/17 02:51 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "pci_register_driver",
  "PathPrefix": "drivers/accel/ivpu"
}

Results: 
{
  "error": "no matches"
}
9/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 6169
							output: 33
							thoughts: 23

Thoughts: 
Here's my thought process, summarized as you requested:

**Navigating the IVPU PCI Driver**

Okay, time to dive into the `drivers/accel/ivpu/` directory. Specifically, I need to take a look at the `module_pci_driver` component. I want to understand how it's interfacing with the PCI bus. This should provide insights into the low-level communication and resource allocation of the IVPU hardware. My hypothesis is that a deep understanding of this interaction will be instrumental for the current investigation. Let's get started.

10/2 2026/09/17 02:51 tool grepper
0m Args: 
{
  "Expression": "module_pci_driver",
  "PathPrefix": "drivers/accel/ivpu"
}

Results: 
{
  "Output": "drivers/accel/ivpu/ivpu_drv.c=898=static struct pci_driver ivpu_pci_driver = {\n--\ndrivers/accel/ivpu/ivpu_drv.c-908-\ndrivers/accel/ivpu/ivpu_drv.c:909:module_pci_driver(ivpu_pci_driver);\ndrivers/accel/ivpu/ivpu_drv.c-910-\n"
}
11/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 6469
							output: 42
							thoughts: 16

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

**Analyzing PCI IDs in ivpu_drv.c**

Alright, let's dive in. I need to get a handle on the PCI device identification within `ivpu_drv.c`. This usually means I'm looking for the standard `pci_device_id` structure, or maybe some custom structures that register device-specific information. My first goal is to locate those ID tables – they're the bread and butter for any driver's interaction with the hardware during initialization and probe. I'll need to figure out which IDs are supported. 
Specifically, I will be looking for the vendor ID and device ID, and also any sub-system information that might be included. The structure probably involves a table of PCI IDs, possibly with an associated function or data pointer to handle the matched device. It's likely that it will be used in the `pci_register_driver` call.
My goal here is to understand the scope of supported devices and see if I can understand which devices the driver will function with, and whether it's safe to load the driver with certain devices.

12/2 2026/09/17 02:51 tool read-file
0m Args: 
{
  "File": "drivers/accel/ivpu/ivpu_drv.c",
  "FirstLine": 880,
  "LineCount": 40
}

Results: 
{
  "Contents": " 880:\tstatic void ivpu_remove(struct pci_dev *pdev)\n 881:\t{\n 882:\t\tstruct ivpu_device *vdev = pci_get_drvdata(pdev);\n 883:\t\n 884:\t\tdrm_dev_unplug(\u0026vdev-\u003edrm);\n 885:\t\tivpu_dev_fini(vdev);\n 886:\t}\n 887:\t\n 888:\tstatic const struct dev_pm_ops ivpu_drv_pci_pm = {\n 889:\t\tSET_SYSTEM_SLEEP_PM_OPS(ivpu_pm_suspend_cb, ivpu_pm_resume_cb)\n 890:\t\tSET_RUNTIME_PM_OPS(ivpu_pm_runtime_suspend_cb, ivpu_pm_runtime_resume_cb, NULL)\n 891:\t};\n 892:\t\n 893:\tstatic const struct pci_error_handlers ivpu_drv_pci_err = {\n 894:\t\t.reset_prepare = ivpu_pm_reset_prepare_cb,\n 895:\t\t.reset_done = ivpu_pm_reset_done_cb,\n 896:\t};\n 897:\t\n 898:\tstatic struct pci_driver ivpu_pci_driver = {\n 899:\t\t.name = KBUILD_MODNAME,\n 900:\t\t.id_table = ivpu_pci_ids,\n 901:\t\t.probe = ivpu_probe,\n 902:\t\t.remove = ivpu_remove,\n 903:\t\t.driver = {\n 904:\t\t\t.pm = \u0026ivpu_drv_pci_pm,\n 905:\t\t},\n 906:\t\t.err_handler = \u0026ivpu_drv_pci_err,\n 907:\t};\n 908:\t\n 909:\tmodule_pci_driver(ivpu_pci_driver);\n 910:\t\n 911:\tMODULE_AUTHOR(\"Intel Corporation\");\n 912:\tMODULE_DESCRIPTION(DRIVER_DESC);\n 913:\tMODULE_LICENSE(\"GPL and additional rights\");\n 914:\tMODULE_VERSION(DRIVER_VERSION_STR);\n"
}
13/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 7368
							output: 34
							thoughts: 13

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

**Checking `ivpu_pci_ids`**

Okay, time to dive in. My immediate thought is, "Let's check the `ivpu_pci_ids` dataset." Given the context, I'm assuming this likely pertains to identifying or validating PCI device information relevant to our work. Perhaps it's a look-up table, a configuration file, or a database containing known identifiers for specific hardware interacting with the IVPU. My objective is likely to quickly ascertain the state of this resource.

I'm probably asking myself a few key questions: "Is the data current? Are the entries complete and accurate? Is the format as expected for integration into the current project or system? Does it contain the expected revisions and model information, or are there any gaps I need to address?" The goal is to quickly assess its suitability for the intended purpose, whether that's device configuration, driver loading, or compatibility checks. If it checks out, great, I can move forward. If not, it's time to flag the discrepancies and outline what needs updating or verification.

14/2 2026/09/17 02:51 tool grepper
0m Args: 
{
  "Expression": "ivpu_pci_ids",
  "PathPrefix": "drivers/accel/ivpu"
}

Results: 
{
  "Output": "drivers/accel/ivpu/ivpu_drv.c=817=static void ivpu_dev_fini(struct ivpu_device *vdev)\n--\ndrivers/accel/ivpu/ivpu_drv.c-841-\ndrivers/accel/ivpu/ivpu_drv.c:842:static struct pci_device_id ivpu_pci_ids[] = {\ndrivers/accel/ivpu/ivpu_drv.c-843-\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },\n--\ndrivers/accel/ivpu/ivpu_drv.c-850-};\ndrivers/accel/ivpu/ivpu_drv.c:851:MODULE_DEVICE_TABLE(pci, ivpu_pci_ids);\ndrivers/accel/ivpu/ivpu_drv.c-852-\n--\ndrivers/accel/ivpu/ivpu_drv.c=898=static struct pci_driver ivpu_pci_driver = {\ndrivers/accel/ivpu/ivpu_drv.c-899-\t.name = KBUILD_MODNAME,\ndrivers/accel/ivpu/ivpu_drv.c:900:\t.id_table = ivpu_pci_ids,\ndrivers/accel/ivpu/ivpu_drv.c-901-\t.probe = ivpu_probe,\n"
}
15/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 8023
							output: 42
							thoughts: 51

Thoughts: 
Here's my thinking process:

**Diving into the PCI Device ID Lookup**

Okay, I need to understand which PCI devices are associated with `ivpu_pci_ids`. The text points me directly to the `ivpu_drv.c` file and, specifically, lines 842-850. To get the full picture, I'll expand the context a bit and look at lines 840 to 860. That should give me the surrounding code and likely the structure where these IDs are defined or used. Hopefully, this context includes comments that clarify the purpose of these IDs. I'm expecting to find a table or some form of data structure defining the PCI vendor and device IDs for the `ivpu` devices. I'm keen to see if there are any specific device classifications or flags associated with these IDs. With this information, I can quickly understand the devices the driver supports or interacts with.

16/2 2026/09/17 02:51 tool read-file
0m Args: 
{
  "File": "drivers/accel/ivpu/ivpu_drv.c",
  "FirstLine": 840,
  "LineCount": 20
}

Results: 
{
  "Contents": " 840:\t}\n 841:\t\n 842:\tstatic struct pci_device_id ivpu_pci_ids[] = {\n 843:\t\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },\n 844:\t\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_ARL) },\n 845:\t\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_LNL) },\n 846:\t\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_PTL_P) },\n 847:\t\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_WCL) },\n 848:\t\t{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_NVL) },\n 849:\t\t{}\n 850:\t};\n 851:\tMODULE_DEVICE_TABLE(pci, ivpu_pci_ids);\n 852:\t\n 853:\tstatic int ivpu_probe(struct pci_dev *pdev, const struct pci_device_id *id)\n 854:\t{\n 855:\t\tstruct ivpu_device *vdev;\n 856:\t\tint ret;\n 857:\t\n 858:\t\tvdev = devm_drm_dev_alloc(\u0026pdev-\u003edev, \u0026driver, struct ivpu_device, drm);\n 859:\t\tif (IS_ERR(vdev))\n"
}
17/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 8728
							output: 32
							thoughts: 290

Thoughts: 
**My Assessment of the WorthFuzzing Criteria**

Okay, let's break this down. I'm reviewing these guidelines to determine if I should set `WorthFuzzing` to `false`. The key negative criteria are those involving code that's fundamentally unreachable. Specifically, they call out structurally unreachable hardware. My initial thought is to consider the Intel NPU, or `ivpu` as it's known internally. It's a new piece of hardware, so I need to verify whether fuzzing is even viable.

The guidelines specifically mention vendor-specific PCIe hardware that *isn't* emulated in standard QEMU. That's the crucial point. So, the question becomes: does Intel's NPU for Meteor Lake, Arrow Lake, Lunar Lake, or Panther Lake require specific physical hardware that's not emulated within standard QEMU or Google Compute Engine? My understanding is, no, standard QEMU *doesn't* emulate it. If that's the case, then without the physical hardware, the `ivpu_probe()` function will never be executed. The `ivpu_probe()` function is the entry point, it's what starts everything.

Furthermore, if `ivpu_probe()` fails, a critical consequence follows: the device node `/dev/accel/accel*` is *only* registered through `ivpu_probe` by way of `drm_dev_register`. So, no probe, no device registration. Therefore, I need to confirm this dependency on `drm_dev_register` by reviewing the `ivpu_drv.c` source code, but given that standard QEMU doesn't emulate the NPU, and that no probe = no device registration, it's pretty clear that anything involving `ivpu` is currently outside the scope of viable fuzzing in our existing environments.

18/2 2026/09/17 02:51 tool grepper
0m Args: 
{
  "Expression": "drm_dev_register",
  "PathPrefix": "drivers/accel/ivpu"
}

Results: 
{
  "Output": "drivers/accel/ivpu/ivpu_drv.c=853=static int ivpu_probe(struct pci_dev *pdev, const struct pci_device_id *id)\n--\ndrivers/accel/ivpu/ivpu_drv.c-870-\ndrivers/accel/ivpu/ivpu_drv.c:871:\tret = drm_dev_register(\u0026vdev-\u003edrm, 0);\ndrivers/accel/ivpu/ivpu_drv.c-872-\tif (ret) {\n"
}
19/2 2026/09/17 02:51 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 9586
							output: 24
							thoughts: 25

Thoughts: 
Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating IVPU Virtualization and Test Framework Integration**

Alright, before I dive too deep into this particular problem, I need to get a lay of the land. First things first, I'm going to quickly check if any of our existing tooling has already addressed the IVPU initialization. Are there any virtual or mock devices floating around that are already set up for IVPU? A pre-built simulation would save me a ton of time and effort down the line. I'm also going to see if any of our test frameworks already handle IVPU initialization as part of their setup. If a framework already initializes the virtual devices, it will eliminate a step from my process. Checking for this early will make it easier to proceed with the specific project at hand.

20/2 2026/09/17 02:52 tool grepper
0m Args: 
{
  "Expression": "ivpu",
  "PathPrefix": "drivers/"
}

Results: 
{
  "Output": "\nFull output is too long, showing 500 out of 7357 lines.\nUse more precise expression if possible.\n\ndrivers/accel/Kconfig=29=source \"drivers/accel/habanalabs/Kconfig\"\ndrivers/accel/Kconfig:30:source \"drivers/accel/ivpu/Kconfig\"\ndrivers/accel/Kconfig-31-source \"drivers/accel/qaic/Kconfig\"\n--\ndrivers/accel/Makefile=5=obj-$(CONFIG_DRM_ACCEL_HABANALABS)\t+= habanalabs/\ndrivers/accel/Makefile:6:obj-$(CONFIG_DRM_ACCEL_IVPU)\t\t+= ivpu/\ndrivers/accel/Makefile-7-obj-$(CONFIG_DRM_ACCEL_QAIC)\t\t+= qaic/\n--\ndrivers/accel/ivpu/Makefile=4=intel_vpu-y := \\\ndrivers/accel/ivpu/Makefile:5:\tivpu_drv.o \\\ndrivers/accel/ivpu/Makefile:6:\tivpu_fw.o \\\ndrivers/accel/ivpu/Makefile:7:\tivpu_fw_log.o \\\ndrivers/accel/ivpu/Makefile:8:\tivpu_gem.o \\\ndrivers/accel/ivpu/Makefile:9:\tivpu_gem_userptr.o \\\ndrivers/accel/ivpu/Makefile:10:\tivpu_hw.o \\\ndrivers/accel/ivpu/Makefile:11:\tivpu_hw_btrs.o \\\ndrivers/accel/ivpu/Makefile:12:\tivpu_hw_ip.o \\\ndrivers/accel/ivpu/Makefile:13:\tivpu_ipc.o \\\ndrivers/accel/ivpu/Makefile:14:\tivpu_job.o \\\ndrivers/accel/ivpu/Makefile:15:\tivpu_jsm_msg.o \\\ndrivers/accel/ivpu/Makefile:16:\tivpu_mmu.o \\\ndrivers/accel/ivpu/Makefile:17:\tivpu_mmu_context.o \\\ndrivers/accel/ivpu/Makefile:18:\tivpu_ms.o \\\ndrivers/accel/ivpu/Makefile:19:\tivpu_pm.o \\\ndrivers/accel/ivpu/Makefile:20:\tivpu_sysfs.o \\\ndrivers/accel/ivpu/Makefile:21:\tivpu_trace_points.o\ndrivers/accel/ivpu/Makefile-22-\ndrivers/accel/ivpu/Makefile:23:intel_vpu-$(CONFIG_DEBUG_FS) += ivpu_debugfs.o\ndrivers/accel/ivpu/Makefile:24:intel_vpu-$(CONFIG_DEV_COREDUMP) += ivpu_coredump.o\ndrivers/accel/ivpu/Makefile-25-\n--\ndrivers/accel/ivpu/Makefile=28=subdir-ccflags-$(CONFIG_DRM_ACCEL_IVPU_DEBUG) += -DDEBUG\ndrivers/accel/ivpu/Makefile-29-\ndrivers/accel/ivpu/Makefile:30:CFLAGS_ivpu_trace_points.o = -I$(src)\n--\ndrivers/accel/ivpu/ivpu_coredump.c-8-\ndrivers/accel/ivpu/ivpu_coredump.c:9:#include \"ivpu_coredump.h\"\ndrivers/accel/ivpu/ivpu_coredump.c:10:#include \"ivpu_fw.h\"\ndrivers/accel/ivpu/ivpu_coredump.c:11:#include \"ivpu_gem.h\"\ndrivers/accel/ivpu/ivpu_coredump.c-12-#include \"vpu_boot_api.h\"\n--\ndrivers/accel/ivpu/ivpu_coredump.c-16-\ndrivers/accel/ivpu/ivpu_coredump.c:17:void ivpu_dev_coredump(struct ivpu_device *vdev)\ndrivers/accel/ivpu/ivpu_coredump.c-18-{\n--\ndrivers/accel/ivpu/ivpu_coredump.c-24-\tcoredump_size = CRASH_DUMP_HEADERS_SIZE + FW_VERSION_HEADER_SIZE +\ndrivers/accel/ivpu/ivpu_coredump.c:25:\t\t\tivpu_bo_size(vdev-\u003efw-\u003emem_log_crit) + ivpu_bo_size(vdev-\u003efw-\u003emem_log_verb);\ndrivers/accel/ivpu/ivpu_coredump.c-26-\tcoredump = vmalloc(coredump_size);\n--\ndrivers/accel/ivpu/ivpu_coredump.c-35-\tdrm_printf(\u0026p, \"FW version: %s\\n\", vdev-\u003efw-\u003eversion);\ndrivers/accel/ivpu/ivpu_coredump.c:36:\tivpu_fw_log_print(vdev, false, \u0026p);\ndrivers/accel/ivpu/ivpu_coredump.c-37-\n--\ndrivers/accel/ivpu/ivpu_coredump.h-10-\ndrivers/accel/ivpu/ivpu_coredump.h:11:#include \"ivpu_drv.h\"\ndrivers/accel/ivpu/ivpu_coredump.h:12:#include \"ivpu_fw_log.h\"\ndrivers/accel/ivpu/ivpu_coredump.h-13-\ndrivers/accel/ivpu/ivpu_coredump.h-14-#ifdef CONFIG_DEV_COREDUMP\ndrivers/accel/ivpu/ivpu_coredump.h:15:void ivpu_dev_coredump(struct ivpu_device *vdev);\ndrivers/accel/ivpu/ivpu_coredump.h-16-#else\ndrivers/accel/ivpu/ivpu_coredump.h:17:static inline void ivpu_dev_coredump(struct ivpu_device *vdev)\ndrivers/accel/ivpu/ivpu_coredump.h-18-{\n--\ndrivers/accel/ivpu/ivpu_coredump.h-20-\ndrivers/accel/ivpu/ivpu_coredump.h:21:\tivpu_fw_log_print(vdev, false, \u0026p);\ndrivers/accel/ivpu/ivpu_coredump.h-22-}\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-12-\ndrivers/accel/ivpu/ivpu_debugfs.c:13:#include \u003cuapi/drm/ivpu_accel.h\u003e\ndrivers/accel/ivpu/ivpu_debugfs.c-14-\ndrivers/accel/ivpu/ivpu_debugfs.c:15:#include \"ivpu_debugfs.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:16:#include \"ivpu_drv.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:17:#include \"ivpu_fw.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:18:#include \"ivpu_fw_log.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:19:#include \"ivpu_gem.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:20:#include \"ivpu_hw.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:21:#include \"ivpu_jsm_msg.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c:22:#include \"ivpu_pm.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c-23-#include \"vpu_boot_api.h\"\ndrivers/accel/ivpu/ivpu_debugfs.c-24-\ndrivers/accel/ivpu/ivpu_debugfs.c:25:static inline struct ivpu_device *seq_to_ivpu(struct seq_file *s)\ndrivers/accel/ivpu/ivpu_debugfs.c-26-{\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-28-\ndrivers/accel/ivpu/ivpu_debugfs.c:29:\treturn to_ivpu_device(entry-\u003edev);\ndrivers/accel/ivpu/ivpu_debugfs.c-30-}\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=32=static int bo_list_show(struct seq_file *s, void *v)\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-34-\tstruct drm_printer p = drm_seq_file_printer(s);\ndrivers/accel/ivpu/ivpu_debugfs.c:35:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-36-\ndrivers/accel/ivpu/ivpu_debugfs.c:37:\tivpu_bo_list(\u0026vdev-\u003edrm, \u0026p);\ndrivers/accel/ivpu/ivpu_debugfs.c-38-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=42=static int fw_name_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-43-{\ndrivers/accel/ivpu/ivpu_debugfs.c:44:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-45-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=50=static int fw_version_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-51-{\ndrivers/accel/ivpu/ivpu_debugfs.c:52:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-53-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=58=static int fw_trace_capability_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-59-{\ndrivers/accel/ivpu/ivpu_debugfs.c:60:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-61-\tu64 trace_hw_component_mask;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-64-\ndrivers/accel/ivpu/ivpu_debugfs.c:65:\tret = ivpu_jsm_trace_get_capability(vdev, \u0026trace_destination_mask,\ndrivers/accel/ivpu/ivpu_debugfs.c-66-\t\t\t\t\t    \u0026trace_hw_component_mask);\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=76=static int fw_trace_config_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-77-{\ndrivers/accel/ivpu/ivpu_debugfs.c:78:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-79-\t/**\ndrivers/accel/ivpu/ivpu_debugfs.c-80-\t * WA: VPU_JSM_MSG_TRACE_GET_CONFIG command is not working yet,\ndrivers/accel/ivpu/ivpu_debugfs.c:81:\t * so we use values from vdev-\u003efw instead of calling ivpu_jsm_trace_get_config()\ndrivers/accel/ivpu/ivpu_debugfs.c-82-\t */\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=96=static int last_bootmode_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-97-{\ndrivers/accel/ivpu/ivpu_debugfs.c:98:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-99-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=106=static int reset_counter_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-107-{\ndrivers/accel/ivpu/ivpu_debugfs.c:108:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-109-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=114=static int reset_pending_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-115-{\ndrivers/accel/ivpu/ivpu_debugfs.c:116:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-117-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=122=static int firewall_irq_counter_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-123-{\ndrivers/accel/ivpu/ivpu_debugfs.c:124:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-125-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=130=static int engine_reset_counter_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-131-{\ndrivers/accel/ivpu/ivpu_debugfs.c:132:\tstruct ivpu_device *vdev = seq_to_ivpu(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-133-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=151=static int dvfs_mode_get(void *data, u64 *dvfs_mode)\ndrivers/accel/ivpu/ivpu_debugfs.c-152-{\ndrivers/accel/ivpu/ivpu_debugfs.c:153:\tstruct ivpu_device *vdev = (struct ivpu_device *)data;\ndrivers/accel/ivpu/ivpu_debugfs.c-154-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=159=static int dvfs_mode_set(void *data, u64 dvfs_mode)\ndrivers/accel/ivpu/ivpu_debugfs.c-160-{\ndrivers/accel/ivpu/ivpu_debugfs.c:161:\tstruct ivpu_device *vdev = (struct ivpu_device *)data;\ndrivers/accel/ivpu/ivpu_debugfs.c-162-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=170=fw_dyndbg_fops_write(struct file *file, const char __user *user_buf, size_t size, loff_t *pos)\ndrivers/accel/ivpu/ivpu_debugfs.c-171-{\ndrivers/accel/ivpu/ivpu_debugfs.c:172:\tstruct ivpu_device *vdev = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c-173-\tchar buffer[VPU_DYNDBG_CMD_MAX_LEN] = {};\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-182-\ndrivers/accel/ivpu/ivpu_debugfs.c:183:\tivpu_jsm_dyndbg_control(vdev, buffer, size);\ndrivers/accel/ivpu/ivpu_debugfs.c-184-\treturn size;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=193=static int fw_log_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-194-{\ndrivers/accel/ivpu/ivpu_debugfs.c:195:\tstruct ivpu_device *vdev = s-\u003eprivate;\ndrivers/accel/ivpu/ivpu_debugfs.c-196-\tstruct drm_printer p = drm_seq_file_printer(s);\ndrivers/accel/ivpu/ivpu_debugfs.c-197-\ndrivers/accel/ivpu/ivpu_debugfs.c:198:\tivpu_fw_log_print(vdev, true, \u0026p);\ndrivers/accel/ivpu/ivpu_debugfs.c-199-\treturn 0;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=208=fw_log_fops_write(struct file *file, const char __user *user_buf, size_t size, loff_t *pos)\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-210-\tstruct seq_file *s = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c:211:\tstruct ivpu_device *vdev = s-\u003eprivate;\ndrivers/accel/ivpu/ivpu_debugfs.c-212-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-215-\ndrivers/accel/ivpu/ivpu_debugfs.c:216:\tivpu_fw_log_mark_read(vdev);\ndrivers/accel/ivpu/ivpu_debugfs.c-217-\treturn size;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=230=fw_profiling_freq_fops_write(struct file *file, const char __user *user_buf,\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-232-{\ndrivers/accel/ivpu/ivpu_debugfs.c:233:\tstruct ivpu_device *vdev = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c-234-\tbool enable;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-240-\ndrivers/accel/ivpu/ivpu_debugfs.c:241:\tivpu_hw_profiling_freq_drive(vdev, enable);\ndrivers/accel/ivpu/ivpu_debugfs.c-242-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=257=fw_trace_destination_mask_fops_write(struct file *file, const char __user *user_buf,\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-259-{\ndrivers/accel/ivpu/ivpu_debugfs.c:260:\tstruct ivpu_device *vdev = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c:261:\tstruct ivpu_fw_info *fw = vdev-\u003efw;\ndrivers/accel/ivpu/ivpu_debugfs.c-262-\tu32 trace_destination_mask;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-270-\ndrivers/accel/ivpu/ivpu_debugfs.c:271:\tivpu_jsm_trace_set_config(vdev, fw-\u003etrace_level, trace_destination_mask,\ndrivers/accel/ivpu/ivpu_debugfs.c-272-\t\t\t\t  fw-\u003etrace_hw_component_mask);\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=284=fw_trace_hw_comp_mask_fops_write(struct file *file, const char __user *user_buf,\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-286-{\ndrivers/accel/ivpu/ivpu_debugfs.c:287:\tstruct ivpu_device *vdev = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c:288:\tstruct ivpu_fw_info *fw = vdev-\u003efw;\ndrivers/accel/ivpu/ivpu_debugfs.c-289-\tu64 trace_hw_component_mask;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-297-\ndrivers/accel/ivpu/ivpu_debugfs.c:298:\tivpu_jsm_trace_set_config(vdev, fw-\u003etrace_level, fw-\u003etrace_destination_mask,\ndrivers/accel/ivpu/ivpu_debugfs.c-299-\t\t\t\t  trace_hw_component_mask);\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=311=fw_trace_level_fops_write(struct file *file, const char __user *user_buf, size_t size, loff_t *pos)\ndrivers/accel/ivpu/ivpu_debugfs.c-312-{\ndrivers/accel/ivpu/ivpu_debugfs.c:313:\tstruct ivpu_device *vdev = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c:314:\tstruct ivpu_fw_info *fw = vdev-\u003efw;\ndrivers/accel/ivpu/ivpu_debugfs.c-315-\tu32 trace_level;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-323-\ndrivers/accel/ivpu/ivpu_debugfs.c:324:\tivpu_jsm_trace_set_config(vdev, trace_level, fw-\u003etrace_destination_mask,\ndrivers/accel/ivpu/ivpu_debugfs.c-325-\t\t\t\t  fw-\u003etrace_hw_component_mask);\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=336=static ssize_t\ndrivers/accel/ivpu/ivpu_debugfs.c:337:ivpu_force_recovery_fn(struct file *file, const char __user *user_buf, size_t size, loff_t *pos)\ndrivers/accel/ivpu/ivpu_debugfs.c-338-{\ndrivers/accel/ivpu/ivpu_debugfs.c:339:\tstruct ivpu_device *vdev = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c-340-\tint ret;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-344-\ndrivers/accel/ivpu/ivpu_debugfs.c:345:\tret = ivpu_rpm_get(vdev);\ndrivers/accel/ivpu/ivpu_debugfs.c-346-\tif (ret \u003c 0)\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-348-\ndrivers/accel/ivpu/ivpu_debugfs.c:349:\tivpu_pm_trigger_recovery(vdev, \"debugfs\");\ndrivers/accel/ivpu/ivpu_debugfs.c-350-\tflush_work(\u0026vdev-\u003epm-\u003erecovery_work);\ndrivers/accel/ivpu/ivpu_debugfs.c:351:\tivpu_rpm_put(vdev);\ndrivers/accel/ivpu/ivpu_debugfs.c-352-\treturn size;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-354-\ndrivers/accel/ivpu/ivpu_debugfs.c:355:static const struct file_operations ivpu_force_recovery_fops = {\ndrivers/accel/ivpu/ivpu_debugfs.c-356-\t.owner = THIS_MODULE,\ndrivers/accel/ivpu/ivpu_debugfs.c-357-\t.open = simple_open,\ndrivers/accel/ivpu/ivpu_debugfs.c:358:\t.write = ivpu_force_recovery_fn,\ndrivers/accel/ivpu/ivpu_debugfs.c-359-};\ndrivers/accel/ivpu/ivpu_debugfs.c-360-\ndrivers/accel/ivpu/ivpu_debugfs.c:361:static int ivpu_reset_engine_fn(void *data, u64 val)\ndrivers/accel/ivpu/ivpu_debugfs.c-362-{\ndrivers/accel/ivpu/ivpu_debugfs.c:363:\tstruct ivpu_device *vdev = (struct ivpu_device *)data;\ndrivers/accel/ivpu/ivpu_debugfs.c-364-\tstruct vpu_jsm_msg resp;\ndrivers/accel/ivpu/ivpu_debugfs.c-365-\ndrivers/accel/ivpu/ivpu_debugfs.c:366:\treturn ivpu_jsm_reset_engine(vdev, (u32)val, \u0026resp);\ndrivers/accel/ivpu/ivpu_debugfs.c-367-}\ndrivers/accel/ivpu/ivpu_debugfs.c-368-\ndrivers/accel/ivpu/ivpu_debugfs.c:369:DEFINE_DEBUGFS_ATTRIBUTE(ivpu_reset_engine_fops, NULL, ivpu_reset_engine_fn, \"0x%02llx\\n\");\ndrivers/accel/ivpu/ivpu_debugfs.c-370-\ndrivers/accel/ivpu/ivpu_debugfs.c:371:static int ivpu_resume_engine_fn(void *data, u64 val)\ndrivers/accel/ivpu/ivpu_debugfs.c-372-{\ndrivers/accel/ivpu/ivpu_debugfs.c:373:\tstruct ivpu_device *vdev = (struct ivpu_device *)data;\ndrivers/accel/ivpu/ivpu_debugfs.c-374-\ndrivers/accel/ivpu/ivpu_debugfs.c:375:\treturn ivpu_jsm_hws_resume_engine(vdev, (u32)val);\ndrivers/accel/ivpu/ivpu_debugfs.c-376-}\ndrivers/accel/ivpu/ivpu_debugfs.c-377-\ndrivers/accel/ivpu/ivpu_debugfs.c:378:DEFINE_DEBUGFS_ATTRIBUTE(ivpu_resume_engine_fops, NULL, ivpu_resume_engine_fn, \"0x%02llx\\n\");\ndrivers/accel/ivpu/ivpu_debugfs.c-379-\ndrivers/accel/ivpu/ivpu_debugfs.c=380=static int dct_active_get(void *data, u64 *active_percent)\ndrivers/accel/ivpu/ivpu_debugfs.c-381-{\ndrivers/accel/ivpu/ivpu_debugfs.c:382:\tstruct ivpu_device *vdev = data;\ndrivers/accel/ivpu/ivpu_debugfs.c-383-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=389=static int dct_active_set(void *data, u64 active_percent)\ndrivers/accel/ivpu/ivpu_debugfs.c-390-{\ndrivers/accel/ivpu/ivpu_debugfs.c:391:\tstruct ivpu_device *vdev = data;\ndrivers/accel/ivpu/ivpu_debugfs.c-392-\tint ret;\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-396-\ndrivers/accel/ivpu/ivpu_debugfs.c:397:\tret = ivpu_rpm_get(vdev);\ndrivers/accel/ivpu/ivpu_debugfs.c-398-\tif (ret \u003c 0)\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-401-\tif (active_percent)\ndrivers/accel/ivpu/ivpu_debugfs.c:402:\t\tret = ivpu_pm_dct_enable(vdev, active_percent);\ndrivers/accel/ivpu/ivpu_debugfs.c-403-\telse\ndrivers/accel/ivpu/ivpu_debugfs.c:404:\t\tret = ivpu_pm_dct_disable(vdev);\ndrivers/accel/ivpu/ivpu_debugfs.c-405-\ndrivers/accel/ivpu/ivpu_debugfs.c:406:\tivpu_rpm_put(vdev);\ndrivers/accel/ivpu/ivpu_debugfs.c-407-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-410-\ndrivers/accel/ivpu/ivpu_debugfs.c:411:DEFINE_DEBUGFS_ATTRIBUTE(ivpu_dct_fops, dct_active_get, dct_active_set, \"%llu\\n\");\ndrivers/accel/ivpu/ivpu_debugfs.c-412-\ndrivers/accel/ivpu/ivpu_debugfs.c:413:static void print_priority_band(struct seq_file *s, struct ivpu_hw_info *hw,\ndrivers/accel/ivpu/ivpu_debugfs.c-414-\t\t\t\tint band, const char *name)\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=423=static int priority_bands_show(struct seq_file *s, void *v)\ndrivers/accel/ivpu/ivpu_debugfs.c-424-{\ndrivers/accel/ivpu/ivpu_debugfs.c:425:\tstruct ivpu_device *vdev = s-\u003eprivate;\ndrivers/accel/ivpu/ivpu_debugfs.c:426:\tstruct ivpu_hw_info *hw = vdev-\u003ehw;\ndrivers/accel/ivpu/ivpu_debugfs.c-427-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c=442=priority_bands_fops_write(struct file *file, const char __user *user_buf, size_t size, loff_t *pos)\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-444-\tstruct seq_file *s = file-\u003eprivate_data;\ndrivers/accel/ivpu/ivpu_debugfs.c:445:\tstruct ivpu_device *vdev = s-\u003eprivate;\ndrivers/accel/ivpu/ivpu_debugfs.c-446-\tchar buf[64];\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-475-\ndrivers/accel/ivpu/ivpu_debugfs.c:476:static const struct file_operations ivpu_hws_priority_bands_fops = {\ndrivers/accel/ivpu/ivpu_debugfs.c-477-\t.owner = THIS_MODULE,\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-484-\ndrivers/accel/ivpu/ivpu_debugfs.c:485:void ivpu_debugfs_init(struct ivpu_device *vdev)\ndrivers/accel/ivpu/ivpu_debugfs.c-486-{\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-491-\tdebugfs_create_file(\"force_recovery\", 0200, debugfs_root, vdev,\ndrivers/accel/ivpu/ivpu_debugfs.c:492:\t\t\t    \u0026ivpu_force_recovery_fops);\ndrivers/accel/ivpu/ivpu_debugfs.c-493-\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-507-\tdebugfs_create_file(\"hws_priority_bands\", 0200, debugfs_root, vdev,\ndrivers/accel/ivpu/ivpu_debugfs.c:508:\t\t\t    \u0026ivpu_hws_priority_bands_fops);\ndrivers/accel/ivpu/ivpu_debugfs.c-509-\ndrivers/accel/ivpu/ivpu_debugfs.c-510-\tdebugfs_create_file(\"reset_engine\", 0200, debugfs_root, vdev,\ndrivers/accel/ivpu/ivpu_debugfs.c:511:\t\t\t    \u0026ivpu_reset_engine_fops);\ndrivers/accel/ivpu/ivpu_debugfs.c-512-\tdebugfs_create_file(\"resume_engine\", 0200, debugfs_root, vdev,\ndrivers/accel/ivpu/ivpu_debugfs.c:513:\t\t\t    \u0026ivpu_resume_engine_fops);\ndrivers/accel/ivpu/ivpu_debugfs.c-514-\ndrivers/accel/ivpu/ivpu_debugfs.c:515:\tif (ivpu_hw_ip_gen(vdev) \u003e= IVPU_HW_IP_40XX) {\ndrivers/accel/ivpu/ivpu_debugfs.c-516-\t\tdebugfs_create_file(\"fw_profiling_freq_drive\", 0200,\ndrivers/accel/ivpu/ivpu_debugfs.c-517-\t\t\t\t    debugfs_root, vdev, \u0026fw_profiling_freq_fops);\ndrivers/accel/ivpu/ivpu_debugfs.c:518:\t\tdebugfs_create_file(\"dct\", 0644, debugfs_root, vdev, \u0026ivpu_dct_fops);\ndrivers/accel/ivpu/ivpu_debugfs.c-519-\t}\n--\ndrivers/accel/ivpu/ivpu_debugfs.c-521-#ifdef CONFIG_FAULT_INJECTION\ndrivers/accel/ivpu/ivpu_debugfs.c:522:\tfault_create_debugfs_attr(\"fail_hw\", debugfs_root, \u0026ivpu_hw_failure);\ndrivers/accel/ivpu/ivpu_debugfs.c-523-#endif\n--\ndrivers/accel/ivpu/ivpu_debugfs.h-8-\ndrivers/accel/ivpu/ivpu_debugfs.h:9:struct ivpu_device;\ndrivers/accel/ivpu/ivpu_debugfs.h-10-\ndrivers/accel/ivpu/ivpu_debugfs.h-11-#if defined(CONFIG_DEBUG_FS)\ndrivers/accel/ivpu/ivpu_debugfs.h:12:void ivpu_debugfs_init(struct ivpu_device *vdev);\ndrivers/accel/ivpu/ivpu_debugfs.h-13-#else\ndrivers/accel/ivpu/ivpu_debugfs.h:14:static inline void ivpu_debugfs_init(struct ivpu_device *vdev) { }\ndrivers/accel/ivpu/ivpu_debugfs.h-15-#endif\n--\ndrivers/accel/ivpu/ivpu_drv.c-18-\ndrivers/accel/ivpu/ivpu_drv.c:19:#include \"ivpu_coredump.h\"\ndrivers/accel/ivpu/ivpu_drv.c:20:#include \"ivpu_debugfs.h\"\ndrivers/accel/ivpu/ivpu_drv.c:21:#include \"ivpu_drv.h\"\ndrivers/accel/ivpu/ivpu_drv.c:22:#include \"ivpu_fw.h\"\ndrivers/accel/ivpu/ivpu_drv.c:23:#include \"ivpu_fw_log.h\"\ndrivers/accel/ivpu/ivpu_drv.c:24:#include \"ivpu_gem.h\"\ndrivers/accel/ivpu/ivpu_drv.c:25:#include \"ivpu_hw.h\"\ndrivers/accel/ivpu/ivpu_drv.c:26:#include \"ivpu_ipc.h\"\ndrivers/accel/ivpu/ivpu_drv.c:27:#include \"ivpu_job.h\"\ndrivers/accel/ivpu/ivpu_drv.c:28:#include \"ivpu_jsm_msg.h\"\ndrivers/accel/ivpu/ivpu_drv.c:29:#include \"ivpu_mmu.h\"\ndrivers/accel/ivpu/ivpu_drv.c:30:#include \"ivpu_mmu_context.h\"\ndrivers/accel/ivpu/ivpu_drv.c:31:#include \"ivpu_ms.h\"\ndrivers/accel/ivpu/ivpu_drv.c:32:#include \"ivpu_pm.h\"\ndrivers/accel/ivpu/ivpu_drv.c:33:#include \"ivpu_sysfs.h\"\ndrivers/accel/ivpu/ivpu_drv.c-34-#include \"vpu_boot_api.h\"\n--\ndrivers/accel/ivpu/ivpu_drv.c-39-\ndrivers/accel/ivpu/ivpu_drv.c:40:int ivpu_dbg_mask;\ndrivers/accel/ivpu/ivpu_drv.c:41:module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644);\ndrivers/accel/ivpu/ivpu_drv.c-42-MODULE_PARM_DESC(dbg_mask, \"Driver debug mask. See IVPU_DBG_* macros.\");\ndrivers/accel/ivpu/ivpu_drv.c-43-\ndrivers/accel/ivpu/ivpu_drv.c:44:int ivpu_test_mode;\ndrivers/accel/ivpu/ivpu_drv.c-45-#if IS_ENABLED(CONFIG_DRM_ACCEL_IVPU_DEBUG)\ndrivers/accel/ivpu/ivpu_drv.c:46:module_param_named_unsafe(test_mode, ivpu_test_mode, int, 0644);\ndrivers/accel/ivpu/ivpu_drv.c-47-MODULE_PARM_DESC(test_mode, \"Test mode mask. See IVPU_TEST_MODE_* macros.\");\n--\ndrivers/accel/ivpu/ivpu_drv.c-49-\ndrivers/accel/ivpu/ivpu_drv.c:50:u8 ivpu_pll_min_ratio;\ndrivers/accel/ivpu/ivpu_drv.c:51:module_param_named(pll_min_ratio, ivpu_pll_min_ratio, byte, 0644);\ndrivers/accel/ivpu/ivpu_drv.c-52-MODULE_PARM_DESC(pll_min_ratio, \"Minimum PLL ratio used to set NPU frequency\");\ndrivers/accel/ivpu/ivpu_drv.c-53-\ndrivers/accel/ivpu/ivpu_drv.c:54:u8 ivpu_pll_max_ratio = U8_MAX;\ndrivers/accel/ivpu/ivpu_drv.c:55:module_param_named(pll_max_ratio, ivpu_pll_max_ratio, byte, 0644);\ndrivers/accel/ivpu/ivpu_drv.c-56-MODULE_PARM_DESC(pll_max_ratio, \"Maximum PLL ratio used to set NPU frequency\");\ndrivers/accel/ivpu/ivpu_drv.c-57-\ndrivers/accel/ivpu/ivpu_drv.c:58:int ivpu_sched_mode = IVPU_SCHED_MODE_AUTO;\ndrivers/accel/ivpu/ivpu_drv.c:59:module_param_named(sched_mode, ivpu_sched_mode, int, 0444);\ndrivers/accel/ivpu/ivpu_drv.c-60-MODULE_PARM_DESC(sched_mode, \"Scheduler mode: -1 - Use default scheduler, 0 - Use OS scheduler (supported on 27XX - 50XX), 1 - Use HW scheduler\");\ndrivers/accel/ivpu/ivpu_drv.c-61-\ndrivers/accel/ivpu/ivpu_drv.c:62:bool ivpu_disable_mmu_cont_pages;\ndrivers/accel/ivpu/ivpu_drv.c:63:module_param_named(disable_mmu_cont_pages, ivpu_disable_mmu_cont_pages, bool, 0444);\ndrivers/accel/ivpu/ivpu_drv.c-64-MODULE_PARM_DESC(disable_mmu_cont_pages, \"Disable MMU contiguous pages optimization\");\ndrivers/accel/ivpu/ivpu_drv.c-65-\ndrivers/accel/ivpu/ivpu_drv.c:66:bool ivpu_force_snoop;\ndrivers/accel/ivpu/ivpu_drv.c:67:module_param_named(force_snoop, ivpu_force_snoop, bool, 0444);\ndrivers/accel/ivpu/ivpu_drv.c-68-MODULE_PARM_DESC(force_snoop, \"Force snooping for NPU host memory access\");\ndrivers/accel/ivpu/ivpu_drv.c-69-\ndrivers/accel/ivpu/ivpu_drv.c:70:static struct ivpu_user_limits *ivpu_user_limits_alloc(struct ivpu_device *vdev, uid_t uid)\ndrivers/accel/ivpu/ivpu_drv.c-71-{\ndrivers/accel/ivpu/ivpu_drv.c:72:\tstruct ivpu_user_limits *limits;\ndrivers/accel/ivpu/ivpu_drv.c-73-\n--\ndrivers/accel/ivpu/ivpu_drv.c-84-\tif (uid == 0) {\ndrivers/accel/ivpu/ivpu_drv.c:85:\t\tlimits-\u003emax_ctx_count = ivpu_get_context_count(vdev);\ndrivers/accel/ivpu/ivpu_drv.c:86:\t\tlimits-\u003emax_db_count = ivpu_get_doorbell_count(vdev);\ndrivers/accel/ivpu/ivpu_drv.c-87-\t} else {\ndrivers/accel/ivpu/ivpu_drv.c:88:\t\tlimits-\u003emax_ctx_count = ivpu_get_context_count(vdev) / 2;\ndrivers/accel/ivpu/ivpu_drv.c:89:\t\tlimits-\u003emax_db_count = ivpu_get_doorbell_count(vdev) / 2;\ndrivers/accel/ivpu/ivpu_drv.c-90-\t}\n--\ndrivers/accel/ivpu/ivpu_drv.c-96-\ndrivers/accel/ivpu/ivpu_drv.c:97:static struct ivpu_user_limits *ivpu_user_limits_get(struct ivpu_device *vdev)\ndrivers/accel/ivpu/ivpu_drv.c-98-{\ndrivers/accel/ivpu/ivpu_drv.c:99:\tstruct ivpu_user_limits *limits;\ndrivers/accel/ivpu/ivpu_drv.c-100-\tuid_t uid = current_uid().val;\n--\ndrivers/accel/ivpu/ivpu_drv.c-106-\t\t\tif (kref_read(\u0026limits-\u003eref) \u003e= limits-\u003emax_ctx_count) {\ndrivers/accel/ivpu/ivpu_drv.c:107:\t\t\t\tivpu_dbg(vdev, IOCTL, \"User %u exceeded max ctx count %u\\n\", uid,\ndrivers/accel/ivpu/ivpu_drv.c-108-\t\t\t\t\t limits-\u003emax_ctx_count);\n--\ndrivers/accel/ivpu/ivpu_drv.c-116-\ndrivers/accel/ivpu/ivpu_drv.c:117:\treturn ivpu_user_limits_alloc(vdev, uid);\ndrivers/accel/ivpu/ivpu_drv.c-118-}\ndrivers/accel/ivpu/ivpu_drv.c-119-\ndrivers/accel/ivpu/ivpu_drv.c:120:static void ivpu_user_limits_release(struct kref *ref)\ndrivers/accel/ivpu/ivpu_drv.c-121-{\ndrivers/accel/ivpu/ivpu_drv.c:122:\tstruct ivpu_user_limits *limits = container_of(ref, struct ivpu_user_limits, ref);\ndrivers/accel/ivpu/ivpu_drv.c:123:\tstruct ivpu_device *vdev = limits-\u003evdev;\ndrivers/accel/ivpu/ivpu_drv.c-124-\n--\ndrivers/accel/ivpu/ivpu_drv.c-130-\ndrivers/accel/ivpu/ivpu_drv.c:131:static void ivpu_user_limits_put(struct ivpu_device *vdev, struct ivpu_user_limits *limits)\ndrivers/accel/ivpu/ivpu_drv.c-132-{\ndrivers/accel/ivpu/ivpu_drv.c-133-\tguard(mutex)(\u0026vdev-\u003euser_limits_lock);\ndrivers/accel/ivpu/ivpu_drv.c:134:\tkref_put(\u0026limits-\u003eref, ivpu_user_limits_release);\ndrivers/accel/ivpu/ivpu_drv.c-135-}\ndrivers/accel/ivpu/ivpu_drv.c-136-\ndrivers/accel/ivpu/ivpu_drv.c:137:struct ivpu_file_priv *ivpu_file_priv_get(struct ivpu_file_priv *file_priv)\ndrivers/accel/ivpu/ivpu_drv.c-138-{\ndrivers/accel/ivpu/ivpu_drv.c:139:\tstruct ivpu_device *vdev = file_priv-\u003evdev;\ndrivers/accel/ivpu/ivpu_drv.c-140-\n--\ndrivers/accel/ivpu/ivpu_drv.c-142-\ndrivers/accel/ivpu/ivpu_drv.c:143:\tivpu_dbg(vdev, KREF, \"file_priv get: ctx %u refcount %u\\n\",\ndrivers/accel/ivpu/ivpu_drv.c-144-\t\t file_priv-\u003ectx.id, kref_read(\u0026file_priv-\u003eref));\n--\ndrivers/accel/ivpu/ivpu_drv.c-148-\ndrivers/accel/ivpu/ivpu_drv.c:149:static void file_priv_unbind(struct ivpu_device *vdev, struct ivpu_file_priv *file_priv)\ndrivers/accel/ivpu/ivpu_drv.c-150-{\n--\ndrivers/accel/ivpu/ivpu_drv.c-152-\tif (file_priv-\u003ebound) {\ndrivers/accel/ivpu/ivpu_drv.c:153:\t\tivpu_dbg(vdev, FILE, \"file_priv unbind: ctx %u\\n\", file_priv-\u003ectx.id);\ndrivers/accel/ivpu/ivpu_drv.c-154-\ndrivers/accel/ivpu/ivpu_drv.c:155:\t\tivpu_cmdq_release_all_locked(file_priv);\ndrivers/accel/ivpu/ivpu_drv.c:156:\t\tivpu_bo_unbind_all_bos_from_context(vdev, \u0026file_priv-\u003ectx);\ndrivers/accel/ivpu/ivpu_drv.c:157:\t\tivpu_mmu_context_fini(vdev, \u0026file_priv-\u003ectx);\ndrivers/accel/ivpu/ivpu_drv.c-158-\t\tfile_priv-\u003ebound = false;\n--\ndrivers/accel/ivpu/ivpu_drv.c=164=static void file_priv_release(struct kref *ref)\ndrivers/accel/ivpu/ivpu_drv.c-165-{\ndrivers/accel/ivpu/ivpu_drv.c:166:\tstruct ivpu_file_priv *file_priv = container_of(ref, struct ivpu_file_priv, ref);\ndrivers/accel/ivpu/ivpu_drv.c:167:\tstruct ivpu_device *vdev = file_priv-\u003evdev;\ndrivers/accel/ivpu/ivpu_drv.c-168-\ndrivers/accel/ivpu/ivpu_drv.c:169:\tivpu_dbg(vdev, FILE, \"file_priv release: ctx %u bound %d\\n\",\ndrivers/accel/ivpu/ivpu_drv.c-170-\t\t file_priv-\u003ectx.id, (bool)file_priv-\u003ebound);\n--\ndrivers/accel/ivpu/ivpu_drv.c-179-\ndrivers/accel/ivpu/ivpu_drv.c:180:\tivpu_user_limits_put(vdev, file_priv-\u003euser_limits);\ndrivers/accel/ivpu/ivpu_drv.c-181-\tmutex_destroy(\u0026file_priv-\u003ems_lock);\n--\ndrivers/accel/ivpu/ivpu_drv.c-185-\ndrivers/accel/ivpu/ivpu_drv.c:186:void ivpu_file_priv_put(struct ivpu_file_priv **link)\ndrivers/accel/ivpu/ivpu_drv.c-187-{\ndrivers/accel/ivpu/ivpu_drv.c:188:\tstruct ivpu_file_priv *file_priv = *link;\ndrivers/accel/ivpu/ivpu_drv.c:189:\tstruct ivpu_device *vdev = file_priv-\u003evdev;\ndrivers/accel/ivpu/ivpu_drv.c-190-\ndrivers/accel/ivpu/ivpu_drv.c:191:\tivpu_dbg(vdev, KREF, \"file_priv put: ctx %u refcount %u\\n\",\ndrivers/accel/ivpu/ivpu_drv.c-192-\t\t file_priv-\u003ectx.id, kref_read(\u0026file_priv-\u003eref));\n--\ndrivers/accel/ivpu/ivpu_drv.c-197-\ndrivers/accel/ivpu/ivpu_drv.c:198:bool ivpu_is_capable(struct ivpu_device *vdev, u32 capability)\ndrivers/accel/ivpu/ivpu_drv.c-199-{\n--\ndrivers/accel/ivpu/ivpu_drv.c-213-\ndrivers/accel/ivpu/ivpu_drv.c:214:static int ivpu_get_param_ioctl(struct drm_device *dev, void *data, struct drm_file *file)\ndrivers/accel/ivpu/ivpu_drv.c-215-{\ndrivers/accel/ivpu/ivpu_drv.c:216:\tstruct ivpu_file_priv *file_priv = file-\u003edriver_priv;\ndrivers/accel/ivpu/ivpu_drv.c:217:\tstruct ivpu_device *vdev = file_priv-\u003evdev;\ndrivers/accel/ivpu/ivpu_drv.c-218-\tstruct pci_dev *pdev = to_pci_dev(vdev-\u003edrm.dev);\ndrivers/accel/ivpu/ivpu_drv.c:219:\tstruct drm_ivpu_param *args = data;\ndrivers/accel/ivpu/ivpu_drv.c-220-\tint ret = 0;\n--\ndrivers/accel/ivpu/ivpu_drv.c-236-\tcase DRM_IVPU_PARAM_CORE_CLOCK_RATE:\ndrivers/accel/ivpu/ivpu_drv.c:237:\t\targs-\u003evalue = ivpu_hw_btrs_pll_ratio_to_hz(vdev, vdev-\u003ehw-\u003epll.max_ratio);\ndrivers/accel/ivpu/ivpu_drv.c-238-\t\tbreak;\n--\ndrivers/accel/ivpu/ivpu_drv.c-258-\tcase DRM_IVPU_PARAM_ENGINE_HEARTBEAT:\ndrivers/accel/ivpu/ivpu_drv.c:259:\t\tret = ivpu_jsm_get_heartbeat(vdev, args-\u003eindex, \u0026args-\u003evalue);\ndrivers/accel/ivpu/ivpu_drv.c-260-\t\tbreak;\n--\ndrivers/accel/ivpu/ivpu_drv.c-270-\tcase DRM_IVPU_PARAM_CAPABILITIES:\n\n"
}
21/2 2026/09/17 02:52 llm patch-evaluator
0m Model: 
gemini-3.8-flash

Args: 
null

Results: 
null

Tokens: 
							input: 23241
							output: 112
							thoughts: 862

Thoughts: 
**WorthFuzzing Analysis: Intel NPU Driver Update**

Okay, so I've got this patch affecting the `intel_vpu` driver, specifically the `ivpu` driver. That's Intel's Neural Processing Unit, or NPU, introduced in those newer Meteor Lake, Arrow Lake, and Lunar Lake Core Ultra processors. I know this driver pretty well. It's an accelerator driver, binding to PCI devices with those specific Intel vendor and device IDs – the usual suspects for this hardware.

Now, the question is whether this patch is "WorthFuzzing." I need to go through those negative criteria. The relevant one here is "Structurally unreachable hardware."  This seems to fit the bill. I know these NPUs are *dedicated* hardware accelerators, either on-die or PCIe endpoint devices. Standard QEMU, the virtual environment Syzkaller often runs in, *absolutely* does not emulate this kind of hardware. It just can't. You need the physical silicon.

I've checked the modified code: `ivpu_prepare_for_reset`, `ivpu_dev_init`, `ivpu_job_handle_engine_error`, `reset_engine_and_mark_faulty_contexts`, `ivpu_mmu_irq_evtq_handler`, and `ivpu_job_timeout_work`. None of this code can even *execute* in the Syzkaller environment. It's completely unreachable. No Syzkaller pseudo-syscalls or virtual devices for `ivpu` exist.

I rechecked the git diff just to be extra sure: it's all within `drivers/accel/ivpu/`.  No other areas are touched. The changes are exclusively in the Intel NPU driver.

The guidance is clear: hardware like "vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed, ionic, amdgpu)" that require physical ASIC/PCIe cards are *not* emulated in standard QEMU.  Accelerators under `/drivers/accel` like the Habanalabs, Intel IVPU, and Qualcomm QAIC, are explicitly mentioned as needing that physical hardware.

Therefore, `WorthFuzzing` has to be `false`. No doubt. The reasoning is solid: the patch *only* touches the `intel_vpu` driver, which needs physical Intel NPU hardware that's absent in the testing environment, so the code is unreachable. I am setting `FocusSymbols` to `[]` and `EnableConfigs` to `[]` as well.

I'm confident in this analysis. Everything is crystal clear.

22/2 2026/09/17 02:52 tool set-results
0m Args: 
{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Intel NPU (ivpu) driver under drivers/accel/ivpu/. This driver requires physical Intel NPU hardware (found on Meteor Lake and newer Intel CPUs) connected via PCIe, which is not emulated in standard QEMU or cloud VM environments. As a result, the driver cannot probe and the modified code paths are structurally unreachable for syzkaller fuzzing.",
  "WorthFuzzing": false
}

Results: 
{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the Intel NPU (ivpu) driver under drivers/accel/ivpu/. This driver requires physical Intel NPU hardware (found on Meteor Lake and newer Intel CPUs) connected via PCIe, which is not emulated in standard QEMU or cloud VM environments. As a result, the driver cannot probe and the modified code paths are structurally unreachable for syzkaller fuzzing.",
  "WorthFuzzing": false
}
23/1 2026/09/17 02:52 action If
0m Args: 
{
  "WorthFuzzing": false
}

Results: 
null
LLM Calls Summary:
Total Calls Total Tokens Avg Tokens Total Duration (Seconds) Avg Duration (Seconds)
Tool Calls Summary:
Total Calls Total Duration (Seconds) Avg Duration (Seconds)