AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The modified code is within the MediaTek Smart Multimedia Interface (SMI) memory controller driver (drivers/memory/mtk-smi.c), which is a platform driver for MediaTek ARM/ARM64 SoCs. On the target architecture (amd64), this driver is structurally unreachable as the underlying SoC hardware and DeviceTree nodes are not present or emulated in standard virtualized environments (QEMU/GCE).",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit e65a2e73b02ff6b43bbcca2d4fba8c116aae6462\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Sep 28 06:48:20 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c\nindex aaeba8ab211e9..dfc65b208951d 100644\n--- a/drivers/memory/mtk-smi.c\n+++ b/drivers/memory/mtk-smi.c\n@@ -157,6 +157,7 @@ struct mtk_smi_larb { /* larb: local arbiter */\n \tint\t\t\t\tlarbid;\n \tu32\t\t\t\t*mmu;\n \tunsigned char\t\t\t*bank;\n+\tbool\t\t\t\tbound; /* set once the iommu binds us */\n };\n \n static int\n@@ -171,6 +172,11 @@ mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)\n \t\t\tlarb-\u003elarbid = i;\n \t\t\tlarb-\u003emmu = \u0026larb_mmu[i].mmu;\n \t\t\tlarb-\u003ebank = larb_mmu[i].bank;\n+\t\t\t/*\n+\t\t\t * Publish larb-\u003emmu and larb-\u003ebank; pairs with\n+\t\t\t * smp_load_acquire() in mtk_smi_larb_resume().\n+\t\t\t */\n+\t\t\tsmp_store_release(\u0026larb-\u003ebound, true);\n \t\t\treturn 0;\n \t\t}\n \t}\n@@ -180,7 +186,13 @@ mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)\n static void\n mtk_smi_larb_unbind(struct device *dev, struct device *master, void *data)\n {\n-\t/* Do nothing as the iommu is always enabled. */\n+\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\n+\n+\t/*\n+\t * The iommu data recorded at bind time is going away; make the\n+\t * next runtime resume wait for a fresh bind.\n+\t */\n+\tWRITE_ONCE(larb-\u003ebound, false);\n }\n \n static const struct component_ops mtk_smi_larb_component_ops = {\n@@ -697,6 +709,19 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev)\n \tconst struct mtk_smi_larb_gen *larb_gen = larb-\u003elarb_gen;\n \tint ret;\n \n+\t/*\n+\t * With modular builds a consumer device probe can runtime-resume\n+\t * the larb (pm_runtime_get_suppliers()) before the iommu's\n+\t * component master bind has populated larb-\u003emmu and larb-\u003ebank.\n+\t * Fail the resume with -EAGAIN: the larb stays RPM_SUSPENDED and\n+\t * retryable, and the next resume after the bind configures the\n+\t * larb ports.\n+\t */\n+\tif (!smp_load_acquire(\u0026larb-\u003ebound)) {\n+\t\tdev_dbg(dev, \"not yet bound to an iommu, skipping port configuration\\n\");\n+\t\treturn -EAGAIN;\n+\t}\n+\n \tret = clk_bulk_prepare_enable(larb-\u003esmi.clk_num, larb-\u003esmi.clks);\n \tif (ret)\n \t\treturn ret;\n"
}

core

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The modified code is within the MediaTek Smart Multimedia Interface (SMI) memory controller driver (drivers/memory/mtk-smi.c), which is a platform driver for MediaTek ARM/ARM64 SoCs. On the target architecture (amd64), this driver is structurally unreachable as the underlying SoC hardware and DeviceTree nodes are not present or emulated in standard virtualized environments (QEMU/GCE).",
  "WorthFuzzing": false
}

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.

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit e65a2e73b02ff6b43bbcca2d4fba8c116aae6462
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Sep 28 06:48:20 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index aaeba8ab211e9..dfc65b208951d 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -157,6 +157,7 @@ struct mtk_smi_larb { /* larb: local arbiter */
 	int				larbid;
 	u32				*mmu;
 	unsigned char			*bank;
+	bool				bound; /* set once the iommu binds us */
 };
 
 static int
@@ -171,6 +172,11 @@ mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
 			larb->larbid = i;
 			larb->mmu = &larb_mmu[i].mmu;
 			larb->bank = larb_mmu[i].bank;
+			/*
+			 * Publish larb->mmu and larb->bank; pairs with
+			 * smp_load_acquire() in mtk_smi_larb_resume().
+			 */
+			smp_store_release(&larb->bound, true);
 			return 0;
 		}
 	}
@@ -180,7 +186,13 @@ mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
 static void
 mtk_smi_larb_unbind(struct device *dev, struct device *master, void *data)
 {
-	/* Do nothing as the iommu is always enabled. */
+	struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+
+	/*
+	 * The iommu data recorded at bind time is going away; make the
+	 * next runtime resume wait for a fresh bind.
+	 */
+	WRITE_ONCE(larb->bound, false);
 }
 
 static const struct component_ops mtk_smi_larb_component_ops = {
@@ -697,6 +709,19 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
 	const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
 	int ret;
 
+	/*
+	 * With modular builds a consumer device probe can runtime-resume
+	 * the larb (pm_runtime_get_suppliers()) before the iommu's
+	 * component master bind has populated larb->mmu and larb->bank.
+	 * Fail the resume with -EAGAIN: the larb stays RPM_SUSPENDED and
+	 * retryable, and the next resume after the bind configures the
+	 * larb ports.
+	 */
+	if (!smp_load_acquire(&larb->bound)) {
+		dev_dbg(dev, "not yet bound to an iommu, skipping port configuration\n");
+		return -EAGAIN;
+	}
+
 	ret = clk_bulk_prepare_enable(larb->smi.clk_num, larb->smi.clks);
 	if (ret)
 		return ret;

gemini-3.8-flash

null

null

							input: 3495
							output: 29
							thoughts: 160
						

**Evaluating the Patch's Suitability for Syzkaller Fuzzing**

Okay, so I need to decide if this patch is a good candidate for fuzzing with syzkaller. The target architecture is amd64, which is a good starting point. The patch itself touches `drivers/memory/mtk-smi.c`. My first thought is: what *is* `mtk-smi.c`? A quick search tells me it's the MediaTek SMI (Smart Multimedia Interface) driver.

Now, the crucial question: can I even reach this thing in a standard virtualized amd64 environment like GCE or QEMU? I need to figure out if it's even compiled and enabled for that architecture and those kinds of systems. So, I'm going to dive into the code. I need to examine `drivers/memory/mtk-smi.c` itself, and especially the corresponding `Kconfig` file in the same directory. That's where I'll find the architecture dependencies and which devices it supports. I'll probably use `git grep` to look for relevant configuration options, or just read the code directly. That's how I'll know if this is a worthwhile target for fuzzing.

{
  "Expression": "config MTK_SMI",
  "PathPrefix": "drivers/memory"
}

{
  "Output": "drivers/memory/Kconfig=163=config JZ4780_NEMC\n--\ndrivers/memory/Kconfig-171-\ndrivers/memory/Kconfig:172:config MTK_SMI\ndrivers/memory/Kconfig-173-\ttristate \"MediaTek SoC Memory Controller driver\" if COMPILE_TEST\n"
}

gemini-3.8-flash

null

null

							input: 4045
							output: 34
							thoughts: 19
						

Okay, let's dive into this. Here's my take on those instructions:

**Analyzing the Memory Configuration Options**

Alright, the objective is pretty clear. I'm being directed to examine the `drivers/memory/Kconfig` file, specifically around line 172. This strongly suggests we're looking at configuration options related to memory management within the kernel. Given the file and directory, it's highly likely that this section deals with drivers related to specific memory controllers, memory types, or features. My immediate thought is, "What kind of memory controller is likely to have its configuration settings defined around that line?" Is it something common, perhaps dealing with DMA, memory protection, or perhaps a more specialized memory device driver? I'll need to use my experience to quickly identify the memory controller type based on the settings around line 172. I will be looking for:

*   Key configuration symbols: I'll be scanning for `config` directives, looking for symbols that use naming conventions (like `MEMORY_CONTROLLER_`, `DMA_MEMORY_`, or `SRAM_`) that indicate what they control.
*   Dependencies: I'll be paying attention to the `depends on` clauses to see what other system features or hardware features enable or disable the settings.
*   Help text: The help text will tell me precisely what the settings are for.
*   Default Values: Are there any default values that are important to observe?
*   Type of Options: Are they Boolean, string, integer or tristate?

My goal is to quickly understand the memory driver configuration options and their context within the kernel's memory management framework.

{
  "File": "drivers/memory/Kconfig",
  "FirstLine": 170,
  "LineCount": 20
}

{
  "Contents": " 170:\t\t  memory devices such as NAND and SRAM.\n 171:\t\n 172:\tconfig MTK_SMI\n 173:\t\ttristate \"MediaTek SoC Memory Controller driver\" if COMPILE_TEST\n 174:\t\tdepends on ARCH_MEDIATEK || COMPILE_TEST\n 175:\t\thelp\n 176:\t\t  This driver is for the Memory Controller module in MediaTek SoCs,\n 177:\t\t  mainly help enable/disable iommu and control the power domain and\n 178:\t\t  clocks for each local arbiter.\n 179:\t\n 180:\tconfig DA8XX_DDRCTL\n 181:\t\tbool \"Texas Instruments da8xx DDR2/mDDR driver\"\n 182:\t\tdepends on ARCH_DAVINCI_DA8XX || COMPILE_TEST\n 183:\t\thelp\n 184:\t\t  This driver is for the DDR2/mDDR Memory Controller present on\n 185:\t\t  Texas Instruments da8xx SoCs. It's used to tweak various memory\n 186:\t\t  controller configuration options.\n 187:\t\n 188:\tconfig PL353_SMC\n 189:\t\ttristate \"ARM PL35X Static Memory Controller(SMC) driver\"\n"
}

gemini-3.8-flash

null

null

							input: 4787
							output: 37
							thoughts: 55
						

Okay, here's my take on those thoughts, framed as my own mental processing as an embedded systems expert:

**Investigating the MTK_SMI Driver's Dependencies and Hardware Requirements**

Alright, so `MTK_SMI` is the subject at hand. Immediately, my brain flags the conditional dependency: `ARCH_MEDIATEK || COMPILE_TEST`.  That's important. It's either tied to a specific Mediatek architecture, or it's a test module that might be configured differently.  The "compile test" condition likely means it can build without those specific Mediatek requirements, for testing purposes. I need to keep that in mind.

To understand its true nature and the level of hardware integration, I need to look into `drivers/memory/mtk-smi.c`. The probe function is where the magic happens. I'll need to figure out what that driver actually *does* and then I can deduce if the driver requires a specific Device Tree entry or unique hardware assumptions. Does it assume a particular memory map? Does it assume particular registers are available? This is where the details are. I'll be looking for clues in the probe code: Is it using `of_match_table` or similar DT parsing? Does it use `platform_get_resource` or other hardware-specific functions? I'll be looking to see what the driver *expects* in terms of hardware configuration. That'll tell me if I can use it in my context.

{
  "Expression": "mtk_smi_",
  "PathPrefix": "drivers/memory/mtk-smi.c"
}

{
  "Output": "drivers/memory/mtk-smi.c-96-\ndrivers/memory/mtk-smi.c:97:struct mtk_smi_reg_pair {\ndrivers/memory/mtk-smi.c-98-\tunsigned int\t\toffset;\n--\ndrivers/memory/mtk-smi.c-101-\ndrivers/memory/mtk-smi.c:102:enum mtk_smi_type {\ndrivers/memory/mtk-smi.c-103-\tMTK_SMI_GEN1,\n--\ndrivers/memory/mtk-smi.c-108-/* larbs: Require apb/smi clocks while gals is optional. */\ndrivers/memory/mtk-smi.c:109:static const char * const mtk_smi_larb_clks[] = {\"apb\", \"smi\", \"gals\"};\ndrivers/memory/mtk-smi.c-110-#define MTK_SMI_LARB_REQ_CLK_NR\t\t2\n--\ndrivers/memory/mtk-smi.c-116- */\ndrivers/memory/mtk-smi.c:117:static const char * const mtk_smi_common_clks[] = {\"apb\", \"smi\", \"gals0\", \"gals1\"};\ndrivers/memory/mtk-smi.c:118:#define MTK_SMI_CLK_NR_MAX\t\tARRAY_SIZE(mtk_smi_common_clks)\ndrivers/memory/mtk-smi.c-119-#define MTK_SMI_COM_REQ_CLK_NR\t\t2\n--\ndrivers/memory/mtk-smi.c-122-\ndrivers/memory/mtk-smi.c:123:struct mtk_smi_common_plat {\ndrivers/memory/mtk-smi.c:124:\tenum mtk_smi_type\ttype;\ndrivers/memory/mtk-smi.c-125-\tbool\t\t\thas_gals;\n--\ndrivers/memory/mtk-smi.c-127-\ndrivers/memory/mtk-smi.c:128:\tconst struct mtk_smi_reg_pair\t*init;\ndrivers/memory/mtk-smi.c-129-};\ndrivers/memory/mtk-smi.c-130-\ndrivers/memory/mtk-smi.c:131:struct mtk_smi_larb_gen {\ndrivers/memory/mtk-smi.c-132-\tint port_in_larb[MTK_LARB_NR_MAX + 1];\n--\ndrivers/memory/mtk-smi.c=139=struct mtk_smi {\n--\ndrivers/memory/mtk-smi.c-148-\tstruct device\t\t\t*smi_common_dev; /* for sub common */\ndrivers/memory/mtk-smi.c:149:\tconst struct mtk_smi_common_plat *plat;\ndrivers/memory/mtk-smi.c-150-};\ndrivers/memory/mtk-smi.c-151-\ndrivers/memory/mtk-smi.c:152:struct mtk_smi_larb { /* larb: local arbiter */\ndrivers/memory/mtk-smi.c-153-\tstruct mtk_smi\t\t\tsmi;\n--\ndrivers/memory/mtk-smi.c-155-\tstruct device\t\t\t*smi_common_dev; /* common or sub-common dev */\ndrivers/memory/mtk-smi.c:156:\tconst struct mtk_smi_larb_gen\t*larb_gen;\ndrivers/memory/mtk-smi.c-157-\tint\t\t\t\tlarbid;\n--\ndrivers/memory/mtk-smi.c=163=static int\ndrivers/memory/mtk-smi.c:164:mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)\ndrivers/memory/mtk-smi.c-165-{\ndrivers/memory/mtk-smi.c:166:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c:167:\tstruct mtk_smi_larb_iommu *larb_mmu = data;\ndrivers/memory/mtk-smi.c-168-\tunsigned int         i;\n--\ndrivers/memory/mtk-smi.c-176-\t\t\t * Publish larb-\u003emmu and larb-\u003ebank; pairs with\ndrivers/memory/mtk-smi.c:177:\t\t\t * smp_load_acquire() in mtk_smi_larb_resume().\ndrivers/memory/mtk-smi.c-178-\t\t\t */\n--\ndrivers/memory/mtk-smi.c=186=static void\ndrivers/memory/mtk-smi.c:187:mtk_smi_larb_unbind(struct device *dev, struct device *master, void *data)\ndrivers/memory/mtk-smi.c-188-{\ndrivers/memory/mtk-smi.c:189:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c-190-\n--\ndrivers/memory/mtk-smi.c-197-\ndrivers/memory/mtk-smi.c:198:static const struct component_ops mtk_smi_larb_component_ops = {\ndrivers/memory/mtk-smi.c:199:\t.bind = mtk_smi_larb_bind,\ndrivers/memory/mtk-smi.c:200:\t.unbind = mtk_smi_larb_unbind,\ndrivers/memory/mtk-smi.c-201-};\ndrivers/memory/mtk-smi.c-202-\ndrivers/memory/mtk-smi.c:203:static int mtk_smi_larb_config_port_gen1(struct device *dev)\ndrivers/memory/mtk-smi.c-204-{\ndrivers/memory/mtk-smi.c:205:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c:206:\tconst struct mtk_smi_larb_gen *larb_gen = larb-\u003elarb_gen;\ndrivers/memory/mtk-smi.c-207-\tstruct mtk_smi *common = dev_get_drvdata(larb-\u003esmi_common_dev);\n--\ndrivers/memory/mtk-smi.c-234-\ndrivers/memory/mtk-smi.c:235:static int mtk_smi_larb_config_port_mt8167(struct device *dev)\ndrivers/memory/mtk-smi.c-236-{\ndrivers/memory/mtk-smi.c:237:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c-238-\n--\ndrivers/memory/mtk-smi.c-242-\ndrivers/memory/mtk-smi.c:243:static int mtk_smi_larb_config_port_mt8173(struct device *dev)\ndrivers/memory/mtk-smi.c-244-{\ndrivers/memory/mtk-smi.c:245:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c-246-\n--\ndrivers/memory/mtk-smi.c-250-\ndrivers/memory/mtk-smi.c:251:static int mtk_smi_larb_config_port_gen2_general(struct device *dev)\ndrivers/memory/mtk-smi.c-252-{\ndrivers/memory/mtk-smi.c:253:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c-254-\tu32 reg, flags_general = larb-\u003elarb_gen-\u003eflags_general;\n--\ndrivers/memory/mtk-smi.c-297-\ndrivers/memory/mtk-smi.c:298:static const u8 mtk_smi_larb_mt6893_ostd[][SMI_LARB_PORT_NR_MAX] = {\ndrivers/memory/mtk-smi.c-299-\t[0] = {0x2, 0x6, 0x2, 0x2, 0x2, 0x28, 0x18, 0x18, 0x1, 0x1, 0x1, 0x8,\n--\ndrivers/memory/mtk-smi.c-334-\ndrivers/memory/mtk-smi.c:335:static const u8 mtk_smi_larb_mt8186_ostd[][SMI_LARB_PORT_NR_MAX] = {\ndrivers/memory/mtk-smi.c-336-\t[0] = {0x2, 0x1, 0x8, 0x1,},\n--\ndrivers/memory/mtk-smi.c-366-\ndrivers/memory/mtk-smi.c:367:static const u8 mtk_smi_larb_mt8188_ostd[][SMI_LARB_PORT_NR_MAX] = {\ndrivers/memory/mtk-smi.c-368-\t[0] = {0x02, 0x18, 0x22, 0x22, 0x01, 0x02, 0x0a,},\n--\ndrivers/memory/mtk-smi.c-415-\ndrivers/memory/mtk-smi.c:416:static const u8 mtk_smi_larb_mt8192_ostd[][SMI_LARB_PORT_NR_MAX] = {\ndrivers/memory/mtk-smi.c-417-\t[0] = {0x2, 0x2, 0x28, 0xa, 0xc, 0x28,},\n--\ndrivers/memory/mtk-smi.c-447-\ndrivers/memory/mtk-smi.c:448:static const u8 mtk_smi_larb_mt8195_ostd[][SMI_LARB_PORT_NR_MAX] = {\ndrivers/memory/mtk-smi.c-449-\t[0] = {0x0a, 0xc, 0x22, 0x22, 0x01, 0x0a,}, /* larb0 */\n--\ndrivers/memory/mtk-smi.c-492-\ndrivers/memory/mtk-smi.c:493:static const struct mtk_smi_larb_gen mtk_smi_larb_mt2701 = {\ndrivers/memory/mtk-smi.c-494-\t.port_in_larb = {\n--\ndrivers/memory/mtk-smi.c-497-\t},\ndrivers/memory/mtk-smi.c:498:\t.config_port = mtk_smi_larb_config_port_gen1,\ndrivers/memory/mtk-smi.c-499-};\ndrivers/memory/mtk-smi.c-500-\ndrivers/memory/mtk-smi.c:501:static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {\ndrivers/memory/mtk-smi.c:502:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-503-\t.larb_direct_to_common_mask = BIT(8) | BIT(9),      /* bdpsys */\n--\ndrivers/memory/mtk-smi.c-505-\ndrivers/memory/mtk-smi.c:506:static const struct mtk_smi_larb_gen mtk_smi_larb_mt6779 = {\ndrivers/memory/mtk-smi.c:507:\t.config_port  = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-508-\t.larb_direct_to_common_mask =\n--\ndrivers/memory/mtk-smi.c-512-\ndrivers/memory/mtk-smi.c:513:static const struct mtk_smi_larb_gen mtk_smi_larb_mt6893 = {\ndrivers/memory/mtk-smi.c:514:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-515-\t.flags_general\t            = MTK_SMI_FLAG_THRT_UPDATE | MTK_SMI_FLAG_SW_FLAG,\ndrivers/memory/mtk-smi.c:516:\t.ostd\t\t            = mtk_smi_larb_mt6893_ostd,\ndrivers/memory/mtk-smi.c-517-};\ndrivers/memory/mtk-smi.c-518-\ndrivers/memory/mtk-smi.c:519:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8167 = {\ndrivers/memory/mtk-smi.c-520-\t/* mt8167 do not need the port in larb */\ndrivers/memory/mtk-smi.c:521:\t.config_port = mtk_smi_larb_config_port_mt8167,\ndrivers/memory/mtk-smi.c-522-};\ndrivers/memory/mtk-smi.c-523-\ndrivers/memory/mtk-smi.c:524:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8173 = {\ndrivers/memory/mtk-smi.c-525-\t/* mt8173 do not need the port in larb */\ndrivers/memory/mtk-smi.c:526:\t.config_port = mtk_smi_larb_config_port_mt8173,\ndrivers/memory/mtk-smi.c-527-};\ndrivers/memory/mtk-smi.c-528-\ndrivers/memory/mtk-smi.c:529:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {\ndrivers/memory/mtk-smi.c:530:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-531-\t.larb_direct_to_common_mask = BIT(2) | BIT(3) | BIT(7),\n--\ndrivers/memory/mtk-smi.c-534-\ndrivers/memory/mtk-smi.c:535:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8186 = {\ndrivers/memory/mtk-smi.c:536:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-537-\t.flags_general\t            = MTK_SMI_FLAG_SLEEP_CTL,\ndrivers/memory/mtk-smi.c:538:\t.ostd\t\t\t    = mtk_smi_larb_mt8186_ostd,\ndrivers/memory/mtk-smi.c-539-};\ndrivers/memory/mtk-smi.c-540-\ndrivers/memory/mtk-smi.c:541:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8188 = {\ndrivers/memory/mtk-smi.c:542:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-543-\t.flags_general\t            = MTK_SMI_FLAG_THRT_UPDATE | MTK_SMI_FLAG_SW_FLAG |\ndrivers/memory/mtk-smi.c-544-\t\t\t\t      MTK_SMI_FLAG_SLEEP_CTL | MTK_SMI_FLAG_CFG_PORT_SEC_CTL,\ndrivers/memory/mtk-smi.c:545:\t.ostd\t\t            = mtk_smi_larb_mt8188_ostd,\ndrivers/memory/mtk-smi.c-546-};\ndrivers/memory/mtk-smi.c-547-\ndrivers/memory/mtk-smi.c:548:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8192 = {\ndrivers/memory/mtk-smi.c:549:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c:550:\t.ostd\t\t\t    = mtk_smi_larb_mt8192_ostd,\ndrivers/memory/mtk-smi.c-551-};\ndrivers/memory/mtk-smi.c-552-\ndrivers/memory/mtk-smi.c:553:static const struct mtk_smi_larb_gen mtk_smi_larb_mt8195 = {\ndrivers/memory/mtk-smi.c:554:\t.config_port                = mtk_smi_larb_config_port_gen2_general,\ndrivers/memory/mtk-smi.c-555-\t.flags_general\t            = MTK_SMI_FLAG_THRT_UPDATE | MTK_SMI_FLAG_SW_FLAG |\ndrivers/memory/mtk-smi.c-556-\t\t\t\t      MTK_SMI_FLAG_SLEEP_CTL,\ndrivers/memory/mtk-smi.c:557:\t.ostd\t\t            = mtk_smi_larb_mt8195_ostd,\ndrivers/memory/mtk-smi.c-558-};\ndrivers/memory/mtk-smi.c-559-\ndrivers/memory/mtk-smi.c:560:static const struct of_device_id mtk_smi_larb_of_ids[] = {\ndrivers/memory/mtk-smi.c:561:\t{.compatible = \"mediatek,mt2701-smi-larb\", .data = \u0026mtk_smi_larb_mt2701},\ndrivers/memory/mtk-smi.c:562:\t{.compatible = \"mediatek,mt2712-smi-larb\", .data = \u0026mtk_smi_larb_mt2712},\ndrivers/memory/mtk-smi.c:563:\t{.compatible = \"mediatek,mt6779-smi-larb\", .data = \u0026mtk_smi_larb_mt6779},\ndrivers/memory/mtk-smi.c:564:\t{.compatible = \"mediatek,mt6795-smi-larb\", .data = \u0026mtk_smi_larb_mt8173},\ndrivers/memory/mtk-smi.c:565:\t{.compatible = \"mediatek,mt6893-smi-larb\", .data = \u0026mtk_smi_larb_mt6893},\ndrivers/memory/mtk-smi.c:566:\t{.compatible = \"mediatek,mt8167-smi-larb\", .data = \u0026mtk_smi_larb_mt8167},\ndrivers/memory/mtk-smi.c:567:\t{.compatible = \"mediatek,mt8173-smi-larb\", .data = \u0026mtk_smi_larb_mt8173},\ndrivers/memory/mtk-smi.c:568:\t{.compatible = \"mediatek,mt8183-smi-larb\", .data = \u0026mtk_smi_larb_mt8183},\ndrivers/memory/mtk-smi.c:569:\t{.compatible = \"mediatek,mt8186-smi-larb\", .data = \u0026mtk_smi_larb_mt8186},\ndrivers/memory/mtk-smi.c:570:\t{.compatible = \"mediatek,mt8188-smi-larb\", .data = \u0026mtk_smi_larb_mt8188},\ndrivers/memory/mtk-smi.c:571:\t{.compatible = \"mediatek,mt8192-smi-larb\", .data = \u0026mtk_smi_larb_mt8192},\ndrivers/memory/mtk-smi.c:572:\t{.compatible = \"mediatek,mt8195-smi-larb\", .data = \u0026mtk_smi_larb_mt8195},\ndrivers/memory/mtk-smi.c-573-\t{}\ndrivers/memory/mtk-smi.c-574-};\ndrivers/memory/mtk-smi.c:575:MODULE_DEVICE_TABLE(of, mtk_smi_larb_of_ids);\ndrivers/memory/mtk-smi.c-576-\ndrivers/memory/mtk-smi.c:577:static int mtk_smi_larb_sleep_ctrl_enable(struct mtk_smi_larb *larb)\ndrivers/memory/mtk-smi.c-578-{\n--\ndrivers/memory/mtk-smi.c-591-\ndrivers/memory/mtk-smi.c:592:static void mtk_smi_larb_sleep_ctrl_disable(struct mtk_smi_larb *larb)\ndrivers/memory/mtk-smi.c-593-{\n--\ndrivers/memory/mtk-smi.c-596-\ndrivers/memory/mtk-smi.c:597:static int mtk_smi_device_link_common(struct device *dev, struct device **com_dev)\ndrivers/memory/mtk-smi.c-598-{\n--\ndrivers/memory/mtk-smi.c-634-\ndrivers/memory/mtk-smi.c:635:static int mtk_smi_dts_clk_init(struct device *dev, struct mtk_smi *smi,\ndrivers/memory/mtk-smi.c-636-\t\t\t\tconst char * const clks[],\n--\ndrivers/memory/mtk-smi.c-655-\ndrivers/memory/mtk-smi.c:656:static int mtk_smi_larb_probe(struct platform_device *pdev)\ndrivers/memory/mtk-smi.c-657-{\ndrivers/memory/mtk-smi.c:658:\tstruct mtk_smi_larb *larb;\ndrivers/memory/mtk-smi.c-659-\tstruct device *dev = \u0026pdev-\u003edev;\n--\ndrivers/memory/mtk-smi.c-670-\ndrivers/memory/mtk-smi.c:671:\tret = mtk_smi_dts_clk_init(dev, \u0026larb-\u003esmi, mtk_smi_larb_clks,\ndrivers/memory/mtk-smi.c-672-\t\t\t\t   MTK_SMI_LARB_REQ_CLK_NR, MTK_SMI_LARB_OPT_CLK_NR);\n--\ndrivers/memory/mtk-smi.c-677-\ndrivers/memory/mtk-smi.c:678:\tret = mtk_smi_device_link_common(dev, \u0026larb-\u003esmi_common_dev);\ndrivers/memory/mtk-smi.c-679-\tif (ret \u003c 0)\n--\ndrivers/memory/mtk-smi.c-683-\tplatform_set_drvdata(pdev, larb);\ndrivers/memory/mtk-smi.c:684:\tret = component_add(dev, \u0026mtk_smi_larb_component_ops);\ndrivers/memory/mtk-smi.c-685-\tif (ret)\n--\ndrivers/memory/mtk-smi.c-695-\ndrivers/memory/mtk-smi.c:696:static void mtk_smi_larb_remove(struct platform_device *pdev)\ndrivers/memory/mtk-smi.c-697-{\ndrivers/memory/mtk-smi.c:698:\tstruct mtk_smi_larb *larb = platform_get_drvdata(pdev);\ndrivers/memory/mtk-smi.c-699-\n--\ndrivers/memory/mtk-smi.c-701-\tpm_runtime_disable(\u0026pdev-\u003edev);\ndrivers/memory/mtk-smi.c:702:\tcomponent_del(\u0026pdev-\u003edev, \u0026mtk_smi_larb_component_ops);\ndrivers/memory/mtk-smi.c-703-\tput_device(larb-\u003esmi_common_dev);\n--\ndrivers/memory/mtk-smi.c-705-\ndrivers/memory/mtk-smi.c:706:static int __maybe_unused mtk_smi_larb_resume(struct device *dev)\ndrivers/memory/mtk-smi.c-707-{\ndrivers/memory/mtk-smi.c:708:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c:709:\tconst struct mtk_smi_larb_gen *larb_gen = larb-\u003elarb_gen;\ndrivers/memory/mtk-smi.c-710-\tint ret;\n--\ndrivers/memory/mtk-smi.c-729-\tif (MTK_SMI_CAPS(larb-\u003elarb_gen-\u003eflags_general, MTK_SMI_FLAG_SLEEP_CTL))\ndrivers/memory/mtk-smi.c:730:\t\tmtk_smi_larb_sleep_ctrl_disable(larb);\ndrivers/memory/mtk-smi.c-731-\n--\ndrivers/memory/mtk-smi.c-735-\ndrivers/memory/mtk-smi.c:736:static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)\ndrivers/memory/mtk-smi.c-737-{\ndrivers/memory/mtk-smi.c:738:\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c-739-\tint ret;\n--\ndrivers/memory/mtk-smi.c-741-\tif (MTK_SMI_CAPS(larb-\u003elarb_gen-\u003eflags_general, MTK_SMI_FLAG_SLEEP_CTL)) {\ndrivers/memory/mtk-smi.c:742:\t\tret = mtk_smi_larb_sleep_ctrl_enable(larb);\ndrivers/memory/mtk-smi.c-743-\t\tif (ret)\n--\ndrivers/memory/mtk-smi.c=751=static const struct dev_pm_ops smi_larb_pm_ops = {\ndrivers/memory/mtk-smi.c:752:\tSET_RUNTIME_PM_OPS(mtk_smi_larb_suspend, mtk_smi_larb_resume, NULL)\ndrivers/memory/mtk-smi.c-753-\tSET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,\n--\ndrivers/memory/mtk-smi.c-756-\ndrivers/memory/mtk-smi.c:757:static struct platform_driver mtk_smi_larb_driver = {\ndrivers/memory/mtk-smi.c:758:\t.probe\t= mtk_smi_larb_probe,\ndrivers/memory/mtk-smi.c:759:\t.remove = mtk_smi_larb_remove,\ndrivers/memory/mtk-smi.c-760-\t.driver\t= {\ndrivers/memory/mtk-smi.c-761-\t\t.name = \"mtk-smi-larb\",\ndrivers/memory/mtk-smi.c:762:\t\t.of_match_table = mtk_smi_larb_of_ids,\ndrivers/memory/mtk-smi.c-763-\t\t.pm             = \u0026smi_larb_pm_ops,\n--\ndrivers/memory/mtk-smi.c-766-\ndrivers/memory/mtk-smi.c:767:static const struct mtk_smi_reg_pair mtk_smi_common_mt6795_init[SMI_COMMON_INIT_REGS_NR] = {\ndrivers/memory/mtk-smi.c-768-\t{SMI_L1_ARB, 0x1b},\n--\ndrivers/memory/mtk-smi.c-773-\ndrivers/memory/mtk-smi.c:774:static const struct mtk_smi_reg_pair mtk_smi_common_mt8195_init[SMI_COMMON_INIT_REGS_NR] = {\ndrivers/memory/mtk-smi.c-775-\t{SMI_L1LEN, 0xb},\n--\ndrivers/memory/mtk-smi.c-782-\ndrivers/memory/mtk-smi.c:783:static const struct mtk_smi_common_plat mtk_smi_common_gen1 = {\ndrivers/memory/mtk-smi.c-784-\t.type     = MTK_SMI_GEN1,\n--\ndrivers/memory/mtk-smi.c-786-\ndrivers/memory/mtk-smi.c:787:static const struct mtk_smi_common_plat mtk_smi_common_gen2 = {\ndrivers/memory/mtk-smi.c-788-\t.type\t  = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-790-\ndrivers/memory/mtk-smi.c:791:static const struct mtk_smi_common_plat mtk_smi_common_mt6779 = {\ndrivers/memory/mtk-smi.c-792-\t.type\t  = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-797-\ndrivers/memory/mtk-smi.c:798:static const struct mtk_smi_common_plat mtk_smi_common_mt6795 = {\ndrivers/memory/mtk-smi.c-799-\t.type\t  = MTK_SMI_GEN2,\ndrivers/memory/mtk-smi.c-800-\t.bus_sel  = F_MMU1_LARB(0),\ndrivers/memory/mtk-smi.c:801:\t.init     = mtk_smi_common_mt6795_init,\ndrivers/memory/mtk-smi.c-802-};\ndrivers/memory/mtk-smi.c-803-\ndrivers/memory/mtk-smi.c:804:static const struct mtk_smi_common_plat mtk_smi_common_mt6893 = {\ndrivers/memory/mtk-smi.c-805-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-810-\ndrivers/memory/mtk-smi.c:811:static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {\ndrivers/memory/mtk-smi.c-812-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-817-\ndrivers/memory/mtk-smi.c:818:static const struct mtk_smi_common_plat mtk_smi_common_mt8186 = {\ndrivers/memory/mtk-smi.c-819-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-823-\ndrivers/memory/mtk-smi.c:824:static const struct mtk_smi_common_plat mtk_smi_common_mt8188_vdo = {\ndrivers/memory/mtk-smi.c-825-\t.type     = MTK_SMI_GEN2,\ndrivers/memory/mtk-smi.c-826-\t.bus_sel  = F_MMU1_LARB(1) | F_MMU1_LARB(5) | F_MMU1_LARB(7),\ndrivers/memory/mtk-smi.c:827:\t.init     = mtk_smi_common_mt8195_init,\ndrivers/memory/mtk-smi.c-828-};\ndrivers/memory/mtk-smi.c-829-\ndrivers/memory/mtk-smi.c:830:static const struct mtk_smi_common_plat mtk_smi_common_mt8188_vpp = {\ndrivers/memory/mtk-smi.c-831-\t.type     = MTK_SMI_GEN2,\ndrivers/memory/mtk-smi.c-832-\t.bus_sel  = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(7),\ndrivers/memory/mtk-smi.c:833:\t.init     = mtk_smi_common_mt8195_init,\ndrivers/memory/mtk-smi.c-834-};\ndrivers/memory/mtk-smi.c-835-\ndrivers/memory/mtk-smi.c:836:static const struct mtk_smi_common_plat mtk_smi_common_mt8192 = {\ndrivers/memory/mtk-smi.c-837-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-842-\ndrivers/memory/mtk-smi.c:843:static const struct mtk_smi_common_plat mtk_smi_common_mt8195_vdo = {\ndrivers/memory/mtk-smi.c-844-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-847-\t\t    F_MMU1_LARB(7),\ndrivers/memory/mtk-smi.c:848:\t.init     = mtk_smi_common_mt8195_init,\ndrivers/memory/mtk-smi.c-849-};\ndrivers/memory/mtk-smi.c-850-\ndrivers/memory/mtk-smi.c:851:static const struct mtk_smi_common_plat mtk_smi_common_mt8195_vpp = {\ndrivers/memory/mtk-smi.c-852-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-854-\t.bus_sel  = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(7),\ndrivers/memory/mtk-smi.c:855:\t.init     = mtk_smi_common_mt8195_init,\ndrivers/memory/mtk-smi.c-856-};\ndrivers/memory/mtk-smi.c-857-\ndrivers/memory/mtk-smi.c:858:static const struct mtk_smi_common_plat mtk_smi_sub_common_mt8195 = {\ndrivers/memory/mtk-smi.c-859-\t.type     = MTK_SMI_GEN2_SUB_COMM,\n--\ndrivers/memory/mtk-smi.c-862-\ndrivers/memory/mtk-smi.c:863:static const struct mtk_smi_common_plat mtk_smi_common_mt8365 = {\ndrivers/memory/mtk-smi.c-864-\t.type     = MTK_SMI_GEN2,\n--\ndrivers/memory/mtk-smi.c-867-\ndrivers/memory/mtk-smi.c:868:static const struct of_device_id mtk_smi_common_of_ids[] = {\ndrivers/memory/mtk-smi.c:869:\t{.compatible = \"mediatek,mt2701-smi-common\", .data = \u0026mtk_smi_common_gen1},\ndrivers/memory/mtk-smi.c:870:\t{.compatible = \"mediatek,mt2712-smi-common\", .data = \u0026mtk_smi_common_gen2},\ndrivers/memory/mtk-smi.c:871:\t{.compatible = \"mediatek,mt6779-smi-common\", .data = \u0026mtk_smi_common_mt6779},\ndrivers/memory/mtk-smi.c:872:\t{.compatible = \"mediatek,mt6795-smi-common\", .data = \u0026mtk_smi_common_mt6795},\ndrivers/memory/mtk-smi.c:873:\t{.compatible = \"mediatek,mt6893-smi-common\", .data = \u0026mtk_smi_common_mt6893},\ndrivers/memory/mtk-smi.c:874:\t{.compatible = \"mediatek,mt8167-smi-common\", .data = \u0026mtk_smi_common_gen2},\ndrivers/memory/mtk-smi.c:875:\t{.compatible = \"mediatek,mt8173-smi-common\", .data = \u0026mtk_smi_common_gen2},\ndrivers/memory/mtk-smi.c:876:\t{.compatible = \"mediatek,mt8183-smi-common\", .data = \u0026mtk_smi_common_mt8183},\ndrivers/memory/mtk-smi.c:877:\t{.compatible = \"mediatek,mt8186-smi-common\", .data = \u0026mtk_smi_common_mt8186},\ndrivers/memory/mtk-smi.c:878:\t{.compatible = \"mediatek,mt8188-smi-common-vdo\", .data = \u0026mtk_smi_common_mt8188_vdo},\ndrivers/memory/mtk-smi.c:879:\t{.compatible = \"mediatek,mt8188-smi-common-vpp\", .data = \u0026mtk_smi_common_mt8188_vpp},\ndrivers/memory/mtk-smi.c:880:\t{.compatible = \"mediatek,mt8192-smi-common\", .data = \u0026mtk_smi_common_mt8192},\ndrivers/memory/mtk-smi.c:881:\t{.compatible = \"mediatek,mt8195-smi-common-vdo\", .data = \u0026mtk_smi_common_mt8195_vdo},\ndrivers/memory/mtk-smi.c:882:\t{.compatible = \"mediatek,mt8195-smi-common-vpp\", .data = \u0026mtk_smi_common_mt8195_vpp},\ndrivers/memory/mtk-smi.c:883:\t{.compatible = \"mediatek,mt8195-smi-sub-common\", .data = \u0026mtk_smi_sub_common_mt8195},\ndrivers/memory/mtk-smi.c:884:\t{.compatible = \"mediatek,mt8365-smi-common\", .data = \u0026mtk_smi_common_mt8365},\ndrivers/memory/mtk-smi.c-885-\t{}\ndrivers/memory/mtk-smi.c-886-};\ndrivers/memory/mtk-smi.c:887:MODULE_DEVICE_TABLE(of, mtk_smi_common_of_ids);\ndrivers/memory/mtk-smi.c-888-\ndrivers/memory/mtk-smi.c:889:static int mtk_smi_common_probe(struct platform_device *pdev)\ndrivers/memory/mtk-smi.c-890-{\n--\ndrivers/memory/mtk-smi.c-906-\t}\ndrivers/memory/mtk-smi.c:907:\tret = mtk_smi_dts_clk_init(dev, common, mtk_smi_common_clks, clk_required, 0);\ndrivers/memory/mtk-smi.c-908-\tif (ret)\n--\ndrivers/memory/mtk-smi.c-932-\tif (common-\u003eplat-\u003etype == MTK_SMI_GEN2_SUB_COMM) {\ndrivers/memory/mtk-smi.c:933:\t\tret = mtk_smi_device_link_common(dev, \u0026common-\u003esmi_common_dev);\ndrivers/memory/mtk-smi.c-934-\t\tif (ret \u003c 0)\n--\ndrivers/memory/mtk-smi.c-942-\ndrivers/memory/mtk-smi.c:943:static void mtk_smi_common_remove(struct platform_device *pdev)\ndrivers/memory/mtk-smi.c-944-{\n--\ndrivers/memory/mtk-smi.c-952-\ndrivers/memory/mtk-smi.c:953:static int __maybe_unused mtk_smi_common_resume(struct device *dev)\ndrivers/memory/mtk-smi.c-954-{\ndrivers/memory/mtk-smi.c-955-\tstruct mtk_smi *common = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c:956:\tconst struct mtk_smi_reg_pair *init = common-\u003eplat-\u003einit;\ndrivers/memory/mtk-smi.c-957-\tu32 bus_sel = common-\u003eplat-\u003ebus_sel; /* default is 0 */\n--\ndrivers/memory/mtk-smi.c-973-\ndrivers/memory/mtk-smi.c:974:static int __maybe_unused mtk_smi_common_suspend(struct device *dev)\ndrivers/memory/mtk-smi.c-975-{\n--\ndrivers/memory/mtk-smi.c=982=static const struct dev_pm_ops smi_common_pm_ops = {\ndrivers/memory/mtk-smi.c:983:\tSET_RUNTIME_PM_OPS(mtk_smi_common_suspend, mtk_smi_common_resume, NULL)\ndrivers/memory/mtk-smi.c-984-\tSET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,\n--\ndrivers/memory/mtk-smi.c-987-\ndrivers/memory/mtk-smi.c:988:static struct platform_driver mtk_smi_common_driver = {\ndrivers/memory/mtk-smi.c:989:\t.probe\t= mtk_smi_common_probe,\ndrivers/memory/mtk-smi.c:990:\t.remove = mtk_smi_common_remove,\ndrivers/memory/mtk-smi.c-991-\t.driver\t= {\ndrivers/memory/mtk-smi.c-992-\t\t.name = \"mtk-smi-common\",\ndrivers/memory/mtk-smi.c:993:\t\t.of_match_table = mtk_smi_common_of_ids,\ndrivers/memory/mtk-smi.c-994-\t\t.pm             = \u0026smi_common_pm_ops,\n--\ndrivers/memory/mtk-smi.c=998=static struct platform_driver * const smidrivers[] = {\ndrivers/memory/mtk-smi.c:999:\t\u0026mtk_smi_common_driver,\ndrivers/memory/mtk-smi.c:1000:\t\u0026mtk_smi_larb_driver,\ndrivers/memory/mtk-smi.c-1001-};\ndrivers/memory/mtk-smi.c-1002-\ndrivers/memory/mtk-smi.c:1003:static int __init mtk_smi_init(void)\ndrivers/memory/mtk-smi.c-1004-{\n--\ndrivers/memory/mtk-smi.c-1006-}\ndrivers/memory/mtk-smi.c:1007:module_init(mtk_smi_init);\ndrivers/memory/mtk-smi.c-1008-\ndrivers/memory/mtk-smi.c:1009:static void __exit mtk_smi_exit(void)\ndrivers/memory/mtk-smi.c-1010-{\n--\ndrivers/memory/mtk-smi.c-1012-}\ndrivers/memory/mtk-smi.c:1013:module_exit(mtk_smi_exit);\ndrivers/memory/mtk-smi.c-1014-\n"
}

gemini-3.8-flash

null

null

							input: 17175
							output: 21
							thoughts: 975
						

**WorthFuzzing Assessment: mtk-smi.c on amd64**

Okay, let's break this down. `mtk-smi.c` is clearly a platform driver built for MediaTek ARM SoCs. The device identifiers like `mediatek,mt2701-smi-larb` and `mediatek,mt8195-smi-larb` immediately flag this as hardware-specific. The target architecture is `amd64`, which raises a major red flag. Can this driver even *exist* in a standard virtualized environment like GCE or QEMU under amd64?

Following the negative criteria for `WorthFuzzing`, I need to see if it falls into any of those categories. The first that comes to mind is "Structurally unreachable hardware" – that's the big one. This driver is for a MediaTek SoC, which relies heavily on DeviceTree.  amd64 QEMU *does not* emulate MediaTek SoCs. No physical hardware, no relevant PCIe cards...it's a non-starter.

The second criterion, "Unreachable execution paths" is also relevant. The code itself references `of_parse_phandle` and DeviceTree nodes ("mediatek,smi" phandle) in the probe function. The `mtk_smi_device_link_common` function is explicitly trying to link to a MediaTek-specific device node. It needs clocks, memory resources which, again, are not provided in an amd64 environment. We're talking about an ARM SoC memory controller/arbiter driver. It's designed to interface with specific hardware.

Critically, the key point is the target architecture.  `amd64` implies no `ARCH_MEDIATEK` definition. Even if the build system allows compilation of `MTK_SMI` on x86, it's not going to probe, function, or be in any way meaningful on amd64. Even on an ARM64 QEMU (if one were running the code), the device tree for a MediaTek board would need to be specifically loaded. It's not a generic virtualized scenario. I can't think of how a platform device with the necessary resources to instantiate a MediaTek SMI (System Memory Interface) could even be created on amd64. I should verify there are not mock devices in syzkaller.

Therefore, given the target architecture, hardware dependencies, and the nature of the driver, I'm confident that this code is *not* worth fuzzing under these conditions.

{
  "Expression": "CONFIG_MTK_SMI"
}

{
  "Output": "drivers/memory/Makefile=20=obj-$(CONFIG_JZ4780_NEMC)\t+= jz4780-nemc.o\ndrivers/memory/Makefile:21:obj-$(CONFIG_MTK_SMI)\t\t+= mtk-smi.o\ndrivers/memory/Makefile-22-obj-$(CONFIG_DA8XX_DDRCTL)\t+= da8xx-ddrctl.o\n--\ninclude/soc/mediatek/smi.h-11-\ninclude/soc/mediatek/smi.h:12:#if IS_ENABLED(CONFIG_MTK_SMI)\ninclude/soc/mediatek/smi.h-13-\n"
}

gemini-3.8-flash

null

null

							input: 18899
							output: 37
							thoughts: 17
						

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

**Diving into the MIPI CSI-2 Driver: Checking the Header**

Okay, time to get down to brass tacks. I need to understand how the MIPI CSI-2 interface is being handled on this Mediatek SoC. My first move? Let's go straight to the source, the likely definition of the driver's interface in `include/soc/mediatek/smi.h`. That header file is usually the best place to start when digging into Mediatek's hardware-specific drivers. I'm expecting to find the register definitions, data structure declarations, and function prototypes related to the Serial Memory Interface (SMI) controller, which is probably how they're handling the MIPI CSI-2 signals. I want to see how they've abstracted the hardware: Are we talking about direct register access, or are there helper functions and structures to make things more manageable? Are there any obvious hardware errata or quirky workarounds documented in there? It's all about establishing a baseline understanding of the SMI driver's approach. This initial investigation will help me understand the driver's design patterns and give me a framework to go deeper as I start to look at the other driver files.

{
  "File": "include/soc/mediatek/smi.h",
  "FirstLine": 1,
  "LineCount": 50
}

{
  "Contents": "   1:\t/* SPDX-License-Identifier: GPL-2.0-only */\n   2:\t/*\n   3:\t * Copyright (c) 2015-2016 MediaTek Inc.\n   4:\t * Author: Yong Wu \u003cyong.wu@mediatek.com\u003e\n   5:\t */\n   6:\t#ifndef MTK_IOMMU_SMI_H\n   7:\t#define MTK_IOMMU_SMI_H\n   8:\t\n   9:\t#include \u003clinux/bitops.h\u003e\n  10:\t#include \u003clinux/device.h\u003e\n  11:\t\n  12:\t#if IS_ENABLED(CONFIG_MTK_SMI)\n  13:\t\n  14:\tenum iommu_atf_cmd {\n  15:\t\tIOMMU_ATF_CMD_CONFIG_SMI_LARB,\t\t/* For mm master to en/disable iommu */\n  16:\t\tIOMMU_ATF_CMD_CONFIG_INFRA_IOMMU,\t/* For infra master to enable iommu */\n  17:\t\tIOMMU_ATF_CMD_MAX,\n  18:\t};\n  19:\t\n  20:\t#define MTK_SMI_MMU_EN(port)\tBIT(port)\n  21:\t\n  22:\tstruct mtk_smi_larb_iommu {\n  23:\t\tstruct device *dev;\n  24:\t\tunsigned int   mmu;\n  25:\t\tunsigned char  bank[32];\n  26:\t};\n  27:\t\n  28:\t#endif\n  29:\t\n  30:\t#endif\n"
}

gemini-3.8-flash

null

null

							input: 19656
							output: 26
							thoughts: 23
						

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

**Investigating Callers and Inclusion of `mtk_smi_larb_bind`**

Okay, so I need to understand the interaction with this `mtk_smi_larb_bind` function or the header it's defined in. My immediate thought is to trace the usage. The first thing I'm doing is going to go see who *calls* this function. I'll need to identify the call sites – both directly and potentially indirectly, considering things like function pointers or macros that might be involved. Understanding the calling context is critical; what data is being passed, what resources are being managed, and what the expected behavior is when this function executes.

Beyond just the callers, I also need to understand which files directly include the header that defines or declares `mtk_smi_larb_bind`. This will reveal the scope of the function's influence and dependencies within the codebase. Is it widely included, or is it more isolated? A broader inclusion suggests it's a fundamental part of a certain module, whereas a narrow inclusion suggests something more localized, possibly an integration point.

Ultimately, I need a good understanding of where this function is called from, and who even needs it, in order to figure out what it's supposed to do and how to troubleshoot or modify it effectively.

{
  "Expression": "mtk_smi_larb_iommu"
}

{
  "Output": "drivers/iommu/mtk_iommu.c=256=struct mtk_iommu_data {\n--\ndrivers/iommu/mtk_iommu.c-280-\tstruct list_head\t\tlist;\ndrivers/iommu/mtk_iommu.c:281:\tstruct mtk_smi_larb_iommu\tlarb_imu[MTK_LARB_NR_MAX];\ndrivers/iommu/mtk_iommu.c-282-};\n--\ndrivers/iommu/mtk_iommu.c=594=static int mtk_iommu_config(struct mtk_iommu_data *data, struct device *dev,\n--\ndrivers/iommu/mtk_iommu.c-596-{\ndrivers/iommu/mtk_iommu.c:597:\tstruct mtk_smi_larb_iommu    *larb_mmu;\ndrivers/iommu/mtk_iommu.c-598-\tunsigned int                 larbid, portid;\n--\ndrivers/iommu/mtk_iommu_v1.c=106=struct mtk_iommu_v1_data {\n--\ndrivers/iommu/mtk_iommu_v1.c-115-\tstruct dma_iommu_mapping\t*mapping;\ndrivers/iommu/mtk_iommu_v1.c:116:\tstruct mtk_smi_larb_iommu\tlarb_imu[MTK_LARB_NR_MAX];\ndrivers/iommu/mtk_iommu_v1.c-117-\n--\ndrivers/iommu/mtk_iommu_v1.c=242=static void mtk_iommu_v1_config(struct mtk_iommu_v1_data *data,\n--\ndrivers/iommu/mtk_iommu_v1.c-244-{\ndrivers/iommu/mtk_iommu_v1.c:245:\tstruct mtk_smi_larb_iommu    *larb_mmu;\ndrivers/iommu/mtk_iommu_v1.c-246-\tunsigned int                 larbid, portid;\n--\ndrivers/memory/mtk-smi.c=164=mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)\n--\ndrivers/memory/mtk-smi.c-166-\tstruct mtk_smi_larb *larb = dev_get_drvdata(dev);\ndrivers/memory/mtk-smi.c:167:\tstruct mtk_smi_larb_iommu *larb_mmu = data;\ndrivers/memory/mtk-smi.c-168-\tunsigned int         i;\n--\ninclude/soc/mediatek/smi.h=14=enum iommu_atf_cmd {\n--\ninclude/soc/mediatek/smi.h-21-\ninclude/soc/mediatek/smi.h:22:struct mtk_smi_larb_iommu {\ninclude/soc/mediatek/smi.h-23-\tstruct device *dev;\n"
}

gemini-3.8-flash

null

null

							input: 20840
							output: 120
							thoughts: 635
						

**Analysis of MediaTek SMI IOMMU Driver for Fuzzing Suitability**

Okay, let's break this down. I'm looking at `drivers/iommu/mtk_iommu.c`, specifically the MediaTek SMI (Smart Multimedia Interface) driver. This is a MediaTek-specific piece of hardware, designed for their SoCs like MT6779, MT8173, etc. – all ARM or ARM64 based. Crucially, the code tells me `ARCH_MEDIATEK` can't be selected on amd64.

I went digging, checking `arch/x86/Kconfig` and `drivers/memory/Kconfig` to confirm, and yes, `MTK_SMI` depends on either `ARCH_MEDIATEK` or `COMPILE_TEST`. Even with `COMPILE_TEST` enabled, which is useful for cross-compiling or building to test components even if they aren't part of the final build, it's still a platform driver. It's designed to match device IDs defined in `mtk_smi_larb_of_ids` and `mtk_smi_common_of_ids`.

Now, the problem is that standard virtualized environments like QEMU and GCE on amd64 run as x86_64 PC/Q35 machines, which use ACPI. They're emulating standard x86 peripherals. There's no MediaTek SoC hardware there, and, as far as I know, syzkaller doesn't instantiate them either. That's a key point.

The second section of the documentation emphasizes this: we're dealing with "structurally unreachable hardware". Specifically, things like "vendor-specific PCIe switches, SmartNICs, or GPU drivers... requiring physical ASIC/PCIe cards not emulated in standard QEMU". This applies perfectly here. The MediaTek SMI relies on specific hardware that's *not* present or emulated in our target environment (amd64, QEMU/GCE).

The code specifically under scrutiny is `drivers/memory/mtk-smi.c`, and the functions are `mtk_smi_larb_bind()`, `mtk_smi_larb_unbind()`, and `mtk_smi_larb_resume()`. These are fundamentally MediaTek ARM/ARM64 SoC-specific. On amd64, this entire code path is unreachable; it's a dead end.

Therefore, `WorthFuzzing` has to be `false` here. There's no way to reach this code in a standard, emulated amd64 environment. It's a waste of resources.

Okay, let's double-check all the required outputs.

*   `WorthFuzzing: false` – Check.
*   `FocusSymbols: []` – Empty list, because the code isn't relevant – Check.
*   `EnableConfigs: []` – Empty list for same reason – Check.
*   `Reasoning`: Precisely as described, The MediaTek SMI (Smart Multimedia Interface) is a platform driver that is specific to MediaTek ARM SoCs (`ARCH_MEDIATEK`). It cannot be probed or executed in standard virtualized environments (QEMU/GCE) on amd64 as the necessary MediaTek SoC hardware and device trees are not present.

Everything aligns. I'm confident. Let's execute `set-results`.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The modified code is within the MediaTek Smart Multimedia Interface (SMI) memory controller driver (drivers/memory/mtk-smi.c), which is a platform driver for MediaTek ARM/ARM64 SoCs. On the target architecture (amd64), this driver is structurally unreachable as the underlying SoC hardware and DeviceTree nodes are not present or emulated in standard virtualized environments (QEMU/GCE).",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The modified code is within the MediaTek Smart Multimedia Interface (SMI) memory controller driver (drivers/memory/mtk-smi.c), which is a platform driver for MediaTek ARM/ARM64 SoCs. On the target architecture (amd64), this driver is structurally unreachable as the underlying SoC hardware and DeviceTree nodes are not present or emulated in standard virtualized environments (QEMU/GCE).",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null