| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/16 08:08 | flow | patch-triage |
2mArgs:null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"KMSANReasoning": "",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies geni_serial_set_rate() in drivers/tty/serial/qcom_geni_serial.c and clock vote macro definitions in include/linux/soc/qcom/geni-se.h. This driver is dedicated to Qualcomm GENI Serial Engine hardware present exclusively on Qualcomm ARM/ARM64 SoCs. On the target architecture (amd64), this hardware is neither present nor emulated in standard virtualized environments (QEMU/GCE), making the modified code structurally unreachable.",
"WorthFuzzing": false
} |
| 1/1 | 2026/09/16 08:08 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 41bd02fde4ccdd8f34748d711375d3ea95b35d5e\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Wed Sep 16 08:08:12 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c\nindex 3633723acef8d..f7e81b6522550 100644\n--- a/drivers/tty/serial/qcom_geni_serial.c\n+++ b/drivers/tty/serial/qcom_geni_serial.c\n@@ -1482,9 +1482,8 @@ static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)\n \t * Bump up BW vote on CPU and CORE path as driver supports FIFO mode\n \t * only.\n \t */\n-\tavg_bw_core = (baud \u003e 115200) ? Bps_to_icc(CORE_2X_50_MHZ)\n-\t\t\t\t\t\t: GENI_DEFAULT_BW;\n-\tport-\u003ese.icc_paths[GENI_TO_CORE].avg_bw = avg_bw_core;\n+\tavg_bw_core = baud \u003e 115200 ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;\n+\tport-\u003ese.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(avg_bw_core);\n \tport-\u003ese.icc_paths[CPU_TO_GENI].avg_bw = Bps_to_icc(baud);\n \tgeni_icc_set_bw(\u0026port-\u003ese);\n \ndiff --git a/include/linux/soc/qcom/geni-se.h b/include/linux/soc/qcom/geni-se.h\nindex 29a53bbc0dd49..5f18d281e6a42 100644\n--- a/include/linux/soc/qcom/geni-se.h\n+++ b/include/linux/soc/qcom/geni-se.h\n@@ -347,17 +347,12 @@ struct geni_se {\n #define QUP_SE_VERSION_2_5 0x20050000\n \n /*\n- * Define bandwidth thresholds that cause the underlying Core 2X interconnect\n- * clock to run at the named frequency. These baseline values are recommended\n- * by the hardware team, and are not dynamically scaled with GENI bandwidth\n- * beyond basic on/off.\n+ * QUP Core 2X clock votes used by GENI clients through the \"qup-core\" ICC\n+ * path. Values are in Bps and must be converted with Bps_to_icc() before\n+ * setting avg_bw.\n */\n-#define CORE_2X_19_2_MHZ\t\t960\n-#define CORE_2X_50_MHZ\t\t\t2500\n-#define CORE_2X_100_MHZ\t\t\t5000\n-#define CORE_2X_150_MHZ\t\t\t7500\n-#define CORE_2X_200_MHZ\t\t\t10000\n-#define CORE_2X_236_MHZ\t\t\t16383\n+#define CORE_2X_19_2_MHZ\t\t9600000\n+#define CORE_2X_50_MHZ\t\t\t25000000\n \n #define GENI_DEFAULT_BW\t\t\tBps_to_icc(1000)\n \n"
} |
| 2/1 | 2026/09/16 08:08 | agent | patch-evaluator |
2mModel:core Args: null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies geni_serial_set_rate() in drivers/tty/serial/qcom_geni_serial.c and clock vote macro definitions in include/linux/soc/qcom/geni-se.h. This driver is dedicated to Qualcomm GENI Serial Engine hardware present exclusively on Qualcomm ARM/ARM64 SoCs. On the target architecture (amd64), this hardware is neither present nor emulated in standard virtualized environments (QEMU/GCE), making the modified code structurally unreachable.",
"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 41bd02fde4ccdd8f34748d711375d3ea95b35d5e
Author: syz-cluster <triage@syzkaller.com>
Date: Wed Sep 16 08:08:12 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 3633723acef8d..f7e81b6522550 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1482,9 +1482,8 @@ static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)
* Bump up BW vote on CPU and CORE path as driver supports FIFO mode
* only.
*/
- avg_bw_core = (baud > 115200) ? Bps_to_icc(CORE_2X_50_MHZ)
- : GENI_DEFAULT_BW;
- port->se.icc_paths[GENI_TO_CORE].avg_bw = avg_bw_core;
+ avg_bw_core = baud > 115200 ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;
+ port->se.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(avg_bw_core);
port->se.icc_paths[CPU_TO_GENI].avg_bw = Bps_to_icc(baud);
geni_icc_set_bw(&port->se);
diff --git a/include/linux/soc/qcom/geni-se.h b/include/linux/soc/qcom/geni-se.h
index 29a53bbc0dd49..5f18d281e6a42 100644
--- a/include/linux/soc/qcom/geni-se.h
+++ b/include/linux/soc/qcom/geni-se.h
@@ -347,17 +347,12 @@ struct geni_se {
#define QUP_SE_VERSION_2_5 0x20050000
/*
- * Define bandwidth thresholds that cause the underlying Core 2X interconnect
- * clock to run at the named frequency. These baseline values are recommended
- * by the hardware team, and are not dynamically scaled with GENI bandwidth
- * beyond basic on/off.
+ * QUP Core 2X clock votes used by GENI clients through the "qup-core" ICC
+ * path. Values are in Bps and must be converted with Bps_to_icc() before
+ * setting avg_bw.
*/
-#define CORE_2X_19_2_MHZ 960
-#define CORE_2X_50_MHZ 2500
-#define CORE_2X_100_MHZ 5000
-#define CORE_2X_150_MHZ 7500
-#define CORE_2X_200_MHZ 10000
-#define CORE_2X_236_MHZ 16383
+#define CORE_2X_19_2_MHZ 9600000
+#define CORE_2X_50_MHZ 25000000
#define GENI_DEFAULT_BW Bps_to_icc(1000)
|
| 3/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3505 output: 32 thoughts: 118 Thoughts: **Analyzing the Proposed Changes** Okay, so we're looking at a patch targeted for amd64, that's good to know upfront. Now, let's dive into the diff. The file changes listed – `drivers/tty/serial/qcom_geni_serial.c` and `include/linux/soc/qcom/geni-se.h` – immediately tell me we're likely dealing with Qualcomm Geni Serial driver components. I need to understand the scope of these changes. My immediate next step is to examine the Kconfig for both the `.c` and `.h` files. I need to understand the build configuration options involved. Is this a new feature, a bug fix, or a modification to existing functionality? `grepper` is probably the best tool here, or alternatively, I can check the `Kconfig` file in the relevant directory, likely `drivers/tty/serial/Kconfig`. I need to understand how these modules are enabled/disabled and any dependencies. This initial Kconfig inspection will provide crucial context before I dig deeper into the code itself. |
| 4/2 | 2026/09/16 08:08 | tool | grepper |
0mArgs:{
"Expression": "SERIAL_QCOM_GENI",
"PathPrefix": "drivers/tty/serial"
}Results: {
"Output": "drivers/tty/serial/Kconfig=909=config SERIAL_MSM_CONSOLE\n--\ndrivers/tty/serial/Kconfig-914-\ndrivers/tty/serial/Kconfig:915:config SERIAL_QCOM_GENI\ndrivers/tty/serial/Kconfig-916-\ttristate \"Qualcomm on-chip GENI based serial port support\"\n--\ndrivers/tty/serial/Kconfig-920-\ndrivers/tty/serial/Kconfig:921:config SERIAL_QCOM_GENI_CONSOLE\ndrivers/tty/serial/Kconfig-922-\tbool \"Qualcomm GENI Serial Console support\"\ndrivers/tty/serial/Kconfig:923:\tdepends on SERIAL_QCOM_GENI\ndrivers/tty/serial/Kconfig-924-\tselect SERIAL_CORE_CONSOLE\n--\ndrivers/tty/serial/Kconfig-929-\ndrivers/tty/serial/Kconfig:930:config SERIAL_QCOM_GENI_UART_PORTS\ndrivers/tty/serial/Kconfig-931-\tint \"Maximum number of GENI UART ports\"\ndrivers/tty/serial/Kconfig:932:\tdepends on SERIAL_QCOM_GENI\ndrivers/tty/serial/Kconfig-933-\tdefault \"8\"\n--\ndrivers/tty/serial/Makefile=67=obj-$(CONFIG_SERIAL_PMACZILOG)\t\t+= pmac_zilog.o\ndrivers/tty/serial/Makefile:68:obj-$(CONFIG_SERIAL_QCOM_GENI)\t\t+= qcom_geni_serial.o\ndrivers/tty/serial/Makefile-69-obj-$(CONFIG_SERIAL_QE)\t\t\t+= ucc_uart.o\n--\ndrivers/tty/serial/qcom_geni_serial.c=279=static struct qcom_geni_serial_port *get_port_from_line(int line, bool console, struct device *dev)\n--\ndrivers/tty/serial/qcom_geni_serial.c-281-\tstruct qcom_geni_serial_port *port;\ndrivers/tty/serial/qcom_geni_serial.c:282:\tint nr_ports = console ? GENI_UART_CONS_PORTS : CONFIG_SERIAL_QCOM_GENI_UART_PORTS;\ndrivers/tty/serial/qcom_geni_serial.c-283-\n--\ndrivers/tty/serial/qcom_geni_serial.c=451=static int qcom_geni_serial_poll_init(struct uart_port *uport)\n--\ndrivers/tty/serial/qcom_geni_serial.c-468-\ndrivers/tty/serial/qcom_geni_serial.c:469:#ifdef CONFIG_SERIAL_QCOM_GENI_CONSOLE\ndrivers/tty/serial/qcom_geni_serial.c-470-static void qcom_geni_serial_drain_fifo(struct uart_port *uport)\n--\ndrivers/tty/serial/qcom_geni_serial.c=716=static void handle_rx_console(struct uart_port *uport, u32 bytes, bool drop)\n--\ndrivers/tty/serial/qcom_geni_serial.c-719-}\ndrivers/tty/serial/qcom_geni_serial.c:720:#endif /* CONFIG_SERIAL_QCOM_GENI_CONSOLE */\ndrivers/tty/serial/qcom_geni_serial.c-721-\n--\ndrivers/tty/serial/qcom_geni_serial.c=1497=static void qcom_geni_serial_set_termios(struct uart_port *uport,\n--\ndrivers/tty/serial/qcom_geni_serial.c-1601-\ndrivers/tty/serial/qcom_geni_serial.c:1602:#ifdef CONFIG_SERIAL_QCOM_GENI_CONSOLE\ndrivers/tty/serial/qcom_geni_serial.c-1603-static int qcom_geni_console_setup(struct console *co, char *options)\n--\ndrivers/tty/serial/qcom_geni_serial.c=1771=static void console_unregister(struct uart_driver *drv)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1773-}\ndrivers/tty/serial/qcom_geni_serial.c:1774:#endif /* CONFIG_SERIAL_QCOM_GENI_CONSOLE */\ndrivers/tty/serial/qcom_geni_serial.c-1775-\ndrivers/tty/serial/qcom_geni_serial.c=1776=static struct uart_driver qcom_geni_uart_driver = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-1779-\t.dev_name = \"ttyHS\",\ndrivers/tty/serial/qcom_geni_serial.c:1780:\t.nr = CONFIG_SERIAL_QCOM_GENI_UART_PORTS,\ndrivers/tty/serial/qcom_geni_serial.c-1781-};\n--\ndrivers/tty/serial/qcom_geni_serial.c=1856=static int qcom_geni_serial_probe(struct platform_device *pdev)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1946-\tuport-\u003eirq = irq;\ndrivers/tty/serial/qcom_geni_serial.c:1947:\tuport-\u003ehas_sysrq = IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE);\ndrivers/tty/serial/qcom_geni_serial.c-1948-\n--\ndrivers/tty/serial/qcom_geni_serial.c=2094=static int qcom_geni_serial_resume(struct device *dev)\n--\ndrivers/tty/serial/qcom_geni_serial.c-2112-\ndrivers/tty/serial/qcom_geni_serial.c:2113:#if IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE)\ndrivers/tty/serial/qcom_geni_serial.c-2114-static const struct qcom_geni_device_data qcom_geni_console_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c=2165=static const struct of_device_id qcom_geni_serial_match_table[] = {\ndrivers/tty/serial/qcom_geni_serial.c:2166:#if IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE)\ndrivers/tty/serial/qcom_geni_serial.c-2167-\t{\n"
} |
| 5/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 5549 output: 36 thoughts: 16 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and presented as if it were my own internal monologue: **Diving into the SERIAL_QCOM_GENI Kconfig** Right, let's pull up the Kconfig file for `SERIAL_QCOM_GENI`. Gotta understand the configuration options and dependencies before I even *think* about touching the driver code itself. Need to see how it's exposed, what other subsystems it leans on, and what platform configurations trigger its inclusion. Is it a direct selection or conditional based on some other feature? Are there any critical dependencies that I need to be aware of right off the bat? Knowing the build-time configuration is the absolute foundation for working with any kernel module. I'm going to start by getting a high-level view of its Kconfig structure. |
| 6/2 | 2026/09/16 08:08 | tool | read-file |
0mArgs:{
"File": "drivers/tty/serial/Kconfig",
"FirstLine": 914,
"LineCount": 30
}Results: {
"Contents": " 914:\t\n 915:\tconfig SERIAL_QCOM_GENI\n 916:\t\ttristate \"Qualcomm on-chip GENI based serial port support\"\n 917:\t\tdepends on ARCH_QCOM || COMPILE_TEST\n 918:\t\tdepends on QCOM_GENI_SE\n 919:\t\tselect SERIAL_CORE\n 920:\t\n 921:\tconfig SERIAL_QCOM_GENI_CONSOLE\n 922:\t\tbool \"Qualcomm GENI Serial Console support\"\n 923:\t\tdepends on SERIAL_QCOM_GENI\n 924:\t\tselect SERIAL_CORE_CONSOLE\n 925:\t\tselect SERIAL_EARLYCON\n 926:\t\thelp\n 927:\t\t Serial console driver for Qualcomm Technologies Inc's GENI based\n 928:\t\t QUP hardware.\n 929:\t\n 930:\tconfig SERIAL_QCOM_GENI_UART_PORTS\n 931:\t\tint \"Maximum number of GENI UART ports\"\n 932:\t\tdepends on SERIAL_QCOM_GENI\n 933:\t\tdefault \"8\"\n 934:\t\thelp\n 935:\t\t Set this to the maximum number of serial ports you want the driver\n 936:\t\t to support.\n 937:\t\n 938:\tconfig SERIAL_VT8500\n 939:\t\tbool \"VIA VT8500 on-chip serial port support\"\n 940:\t\tdepends on ARCH_VT8500 || COMPILE_TEST\n 941:\t\tselect SERIAL_CORE\n 942:\t\n 943:\tconfig SERIAL_VT8500_CONSOLE\n"
} |
| 7/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6215 output: 22 thoughts: 63 Thoughts: **Analyzing the Build Configuration** Okay, let's break this down. I'm seeing `SERIAL_QCOM_GENI` in the configuration files, and it's got a few dependencies: `ARCH_QCOM` or `COMPILE_TEST`, and, crucially, `QCOM_GENI_SE`. Now, `ARCH_QCOM` and `COMPILE_TEST` are pretty straightforward—they likely relate to the target architecture or general build tests. But `QCOM_GENI_SE`... that's the interesting one. I need to understand what that dependency signifies. I'll need to dig into the definition of `QCOM_GENI_SE` to fully grasp the implications for `SERIAL_QCOM_GENI`. That's the next logical step. |
| 8/2 | 2026/09/16 08:08 | tool | grepper |
0mArgs:{
"Expression": "config QCOM_GENI_SE"
}Results: {
"Output": "drivers/soc/qcom/Kconfig=30=config QCOM_COMMAND_DB\n--\ndrivers/soc/qcom/Kconfig-39-\ndrivers/soc/qcom/Kconfig:40:config QCOM_GENI_SE\ndrivers/soc/qcom/Kconfig-41-\ttristate \"Qualcomm GENI Serial Engine Driver\"\n"
} |
| 9/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6566 output: 36 thoughts: 22 Thoughts: Here's my take on those thoughts, tailored for an expert audience: **Diving into the QCOM Kconfig - Line 40** Alright, let's zero in on drivers/soc/qcom/Kconfig, specifically around line 40. My spidey-sense is tingling; this is a spot where interesting things often hide in complex SoCs. Given the naming convention, it's almost certainly related to Qualcomm's System-on-Chip configuration. Kconfig files are the lifeblood of the kernel configuration process – the mechanism we use to build-time select features and options to tailor the kernel to a particular hardware platform. Line 40, within this particular Kconfig, is likely defining a feature or a hardware component for a Qualcomm SoC, and understanding it is paramount for any customized kernel build or debugging of qcom-related subsystems. I need to understand what this config option is doing, what it depends on, and what implications its enablement or disablement has on the system. This probably involves cross-referencing against the source code for the driver itself, and checking for relevant dependencies and select statements in the same Kconfig, and in other Kconfig files that this file might include. This could be a critical setting for a platform-specific feature, or maybe just a relatively innocuous one. I'm going to quickly parse the relevant code to find out. Let's see what we've got. |
| 10/2 | 2026/09/16 08:08 | tool | read-file |
0mArgs:{
"File": "drivers/soc/qcom/Kconfig",
"FirstLine": 35,
"LineCount": 25
}Results: {
"Contents": " 35:\t\t Command DB queries shared memory by key string for shared system\n 36:\t\t resources. Platform drivers that require to set state of a shared\n 37:\t\t resource on a RPM-hardened platform must use this database to get\n 38:\t\t SoC specific identifier and information for the shared resources.\n 39:\t\n 40:\tconfig QCOM_GENI_SE\n 41:\t\ttristate \"Qualcomm GENI Serial Engine Driver\"\n 42:\t\tdepends on ARM64 || COMPILE_TEST\n 43:\t\tdefault ARCH_QCOM\n 44:\t\thelp\n 45:\t\t This driver is used to manage Generic Interface (GENI) firmware based\n 46:\t\t Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This\n 47:\t\t driver is also used to manage the common aspects of multiple Serial\n 48:\t\t Engines present in the QUP.\n 49:\t\n 50:\tconfig QCOM_GSBI\n 51:\t\ttristate \"Qualcomm General Serial Bus Interface\"\n 52:\t\tdepends on ARM || COMPILE_TEST\n 53:\t\tdefault ARCH_QCOM\n 54:\t\tselect MFD_SYSCON\n 55:\t\thelp\n 56:\t\t Say y here to enable GSBI support. The GSBI provides control\n 57:\t\t functions for connecting the underlying serial UART, SPI, and I2C\n 58:\t\t devices to the output pins.\n 59:\t\n"
} |
| 11/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 7301 output: 40 thoughts: 35 Thoughts: **Analyzing the qcom_geni_serial Driver** Okay, let's dive in. My immediate focus is on the `qcom_geni_serial.c` file and its probe function. I need to quickly establish the fundamentals. First, I need to confirm: is `qcom_geni_serial` implemented as a platform driver? That's the baseline question I need an answer to. Gotta start with that to understand the overall architecture. Let's dig in and verify. |
| 12/2 | 2026/09/16 08:08 | tool | grepper |
0mError:no matches Args: {
"Expression": "module_platform_driver",
"PathPrefix": "drivers/tty/serial/qcom_geni_serial.c"
}Results: {
"error": "no matches"
} |
| 13/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 7496 output: 44 thoughts: 24 Thoughts: Here's my summary, as if I were examining the end of `drivers/tty/serial/qcom_geni_serial.c`: **Dissecting the Denouement: QCOM GENI Serial** Alright, let's get down to brass tacks. I'm focusing on the conclusion of this `qcom_geni_serial.c` file. I'm already pretty familiar with the overall QCOM GENI serial architecture, so I'm honing in on how they're handling cleanup, error conditions, and resource release here. I'm expecting to see the standard pattern: spinlocks released, DMA channels freed, interrupts disabled, device nodes unregistered, and the platform data structure (or a related structure) cleaned up meticulously. They've got to be handling power management transitions gracefully, too. I'm particularly interested in seeing how they manage the interrupt handler's interaction with the serial core. Are they using workqueues to defer any potentially slow operations? Are there any subtle race conditions I should be on the lookout for? Given the complexities of the GENI interface, I bet they have some nuanced error handling routines. I'm going to look at the error conditions they're addressing, and see how they are handling potential issues, such as a buffer overflow, or a stalled DMA transfer, or even a failed power transition. I want to see if they've accounted for all the scenarios where things can go sideways, and that they are doing so without leaking resources. I am also looking at the cleanup code, to see how the driver handles shutdown, module unloading, and hotplug events. I'll verify if they have a robust mechanism to tear down the device and return it to a known state. I'm expecting to see a methodical approach here – a well-defined sequence of steps to ensure a clean exit, preventing any lingering devices or potential system instability. I want this to be rock solid, production-ready code. |
| 14/2 | 2026/09/16 08:08 | tool | read-file |
0mArgs:{
"File": "drivers/tty/serial/qcom_geni_serial.c",
"FirstLine": 2160,
"LineCount": 50
}Results: {
"Contents": "2160:\t\n2161:\t\tqcom_geni_serial_stop_tx(uport);\n2162:\t\tqcom_geni_serial_stop_rx(uport);\n2163:\t}\n2164:\t\n2165:\tstatic const struct of_device_id qcom_geni_serial_match_table[] = {\n2166:\t#if IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE)\n2167:\t\t{\n2168:\t\t\t.compatible = \"qcom,geni-debug-uart\",\n2169:\t\t\t.data = \u0026qcom_geni_console_data,\n2170:\t\t},\n2171:\t\t{\n2172:\t\t\t.compatible = \"qcom,sa8255p-geni-debug-uart\",\n2173:\t\t\t.data = \u0026sa8255p_qcom_geni_console_data,\n2174:\t\t},\n2175:\t#endif\n2176:\t\t{\n2177:\t\t\t.compatible = \"qcom,geni-uart\",\n2178:\t\t\t.data = \u0026qcom_geni_uart_data,\n2179:\t\t},\n2180:\t\t{\n2181:\t\t\t.compatible = \"qcom,sa8255p-geni-uart\",\n2182:\t\t\t.data = \u0026sa8255p_qcom_geni_uart_data,\n2183:\t\t},\n2184:\t\t{}\n2185:\t};\n2186:\tMODULE_DEVICE_TABLE(of, qcom_geni_serial_match_table);\n2187:\t\n2188:\tstatic struct platform_driver qcom_geni_serial_platform_driver = {\n2189:\t\t.remove = qcom_geni_serial_remove,\n2190:\t\t.probe = qcom_geni_serial_probe,\n2191:\t\t.shutdown = qcom_geni_serial_sys_shutdown,\n2192:\t\t.driver = {\n2193:\t\t\t.name = \"qcom_geni_serial\",\n2194:\t\t\t.of_match_table = qcom_geni_serial_match_table,\n2195:\t\t\t.pm = \u0026qcom_geni_serial_pm_ops,\n2196:\t\t},\n2197:\t};\n2198:\t\n2199:\tstatic int __init qcom_geni_serial_init(void)\n2200:\t{\n2201:\t\tint ret;\n2202:\t\n2203:\t\tret = console_register(\u0026qcom_geni_console_driver);\n2204:\t\tif (ret)\n2205:\t\t\treturn ret;\n2206:\t\n2207:\t\tret = uart_register_driver(\u0026qcom_geni_uart_driver);\n2208:\t\tif (ret) {\n2209:\t\t\tconsole_unregister(\u0026qcom_geni_console_driver);\n"
} |
| 15/2 | 2026/09/16 08:08 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 8768 output: 44 thoughts: 27 Thoughts: Here's my summary, as though I'm reading and processing the specified lines of code: **Diving into qcom_geni_serial.c: Lines 2205-2235** Okay, let's zero in on lines 2205-2235 within `qcom_geni_serial.c`. Given the file name and the context, I'm expecting this section to deal with the low-level specifics of serial communication on a Qualcomm Geni platform, and I bet it has some specific hardware handling for QCA platforms. As an expert in embedded systems architecture, I'm immediately looking for things like register access, interrupt management, possibly some DMA configuration if it's there. I'm hoping to see if it handles any special features. I'll read with extra care for anything non-standard, and think about how they might optimize serial performance here. I will want to understand the exact mechanics of data transmission and reception, including potential error handling. I'm keen to see the approach for buffering data. The focus should be on the core data path. |
| 16/2 | 2026/09/16 08:09 | tool | read-file |
0mArgs:{
"File": "drivers/tty/serial/qcom_geni_serial.c",
"FirstLine": 2205,
"LineCount": 35
}Results: {
"Contents": "2205:\t\t\treturn ret;\n2206:\t\n2207:\t\tret = uart_register_driver(\u0026qcom_geni_uart_driver);\n2208:\t\tif (ret) {\n2209:\t\t\tconsole_unregister(\u0026qcom_geni_console_driver);\n2210:\t\t\treturn ret;\n2211:\t\t}\n2212:\t\n2213:\t\tret = platform_driver_register(\u0026qcom_geni_serial_platform_driver);\n2214:\t\tif (ret) {\n2215:\t\t\tconsole_unregister(\u0026qcom_geni_console_driver);\n2216:\t\t\tuart_unregister_driver(\u0026qcom_geni_uart_driver);\n2217:\t\t}\n2218:\t\treturn ret;\n2219:\t}\n2220:\tmodule_init(qcom_geni_serial_init);\n2221:\t\n2222:\tstatic void __exit qcom_geni_serial_exit(void)\n2223:\t{\n2224:\t\tplatform_driver_unregister(\u0026qcom_geni_serial_platform_driver);\n2225:\t\tconsole_unregister(\u0026qcom_geni_console_driver);\n2226:\t\tuart_unregister_driver(\u0026qcom_geni_uart_driver);\n2227:\t}\n2228:\tmodule_exit(qcom_geni_serial_exit);\n2229:\t\n2230:\tMODULE_DESCRIPTION(\"Serial driver for GENI based QUP cores\");\n2231:\tMODULE_LICENSE(\"GPL v2\");\n"
} |
| 17/2 | 2026/09/16 08:09 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 9498 output: 44 thoughts: 250 Thoughts: **Analyzing the `qcom_geni_serial` Driver** Okay, let's dive into this `qcom_geni_serial` driver. First, I see it's a platform driver that's keyed off of device tree compatible strings: "qcom,geni-debug-uart," "qcom,sa8255p-geni-debug-uart," "qcom,geni-uart," and "qcom,sa8255p-geni-uart." My immediate thought is, can I even get this thing to probe on an amd64 target, specifically in a standard QEMU environment or even GCE? Hold on... I need to clarify something. Can I even instantiate an OF platform device for `qcom,geni-uart` on an x86_64 system? The real question is, does QEMU on x86_64 even *emulate* Qualcomm GENI QUP hardware? The answer is likely no; Qualcomm GENI is a specific on-chip bus/peripheral controller primarily associated with Qualcomm Snapdragon SoCs, which are ARM/ARM64. But wait, even if someone were clever and used a device tree overlay, or even something like configfs, to *try* to instantiate it on amd64, what would actually happen when the driver's probe function, `qcom_geni_serial_probe`, is called? That's the critical piece. I need to examine `qcom_geni_serial_probe` itself. The emulation aspect means it's unlikely to function in that environment. |
| 18/2 | 2026/09/16 08:09 | tool | read-file |
0mArgs:{
"File": "drivers/tty/serial/qcom_geni_serial.c",
"FirstLine": 1856,
"LineCount": 90
}Results: {
"Contents": "1856:\tstatic int qcom_geni_serial_probe(struct platform_device *pdev)\n1857:\t{\n1858:\t\tint ret = 0;\n1859:\t\tint line;\n1860:\t\tstruct qcom_geni_serial_port *port;\n1861:\t\tstruct uart_port *uport;\n1862:\t\tstruct resource *res;\n1863:\t\tint irq;\n1864:\t\tstruct uart_driver *drv;\n1865:\t\tconst struct qcom_geni_device_data *data;\n1866:\t\n1867:\t\tdata = of_device_get_match_data(\u0026pdev-\u003edev);\n1868:\t\tif (!data)\n1869:\t\t\treturn -EINVAL;\n1870:\t\n1871:\t\tif (data-\u003econsole) {\n1872:\t\t\tdrv = \u0026qcom_geni_console_driver;\n1873:\t\t\tline = of_alias_get_id(pdev-\u003edev.of_node, \"serial\");\n1874:\t\t} else {\n1875:\t\t\tdrv = \u0026qcom_geni_uart_driver;\n1876:\t\t\tline = of_alias_get_id(pdev-\u003edev.of_node, \"serial\");\n1877:\t\t\tif (line == -ENODEV) /* compat with non-standard aliases */\n1878:\t\t\t\tline = of_alias_get_id(pdev-\u003edev.of_node, \"hsuart\");\n1879:\t\t}\n1880:\t\n1881:\t\tport = get_port_from_line(line, data-\u003econsole, \u0026pdev-\u003edev);\n1882:\t\tif (IS_ERR(port)) {\n1883:\t\t\tdev_err(\u0026pdev-\u003edev, \"Invalid line %d\\n\", line);\n1884:\t\t\treturn PTR_ERR(port);\n1885:\t\t}\n1886:\t\n1887:\t\tuport = \u0026port-\u003euport;\n1888:\t\t/* Don't allow 2 drivers to access the same port */\n1889:\t\tif (uport-\u003eprivate_data)\n1890:\t\t\treturn -ENODEV;\n1891:\t\n1892:\t\tuport-\u003edev = \u0026pdev-\u003edev;\n1893:\t\tport-\u003edev_data = data;\n1894:\t\tport-\u003ese.dev = \u0026pdev-\u003edev;\n1895:\t\tport-\u003ese.wrapper = dev_get_drvdata(pdev-\u003edev.parent);\n1896:\t\n1897:\t\tret = port-\u003edev_data-\u003eresources_init(\u0026port-\u003ese);\n1898:\t\tif (ret)\n1899:\t\t\treturn ret;\n1900:\t\n1901:\t\tres = platform_get_resource(pdev, IORESOURCE_MEM, 0);\n1902:\t\tif (!res) {\n1903:\t\t\tret = -EINVAL;\n1904:\t\t\tgoto error;\n1905:\t\t}\n1906:\t\n1907:\t\tuport-\u003emapbase = res-\u003estart;\n1908:\t\n1909:\t\tuport-\u003ers485_config = qcom_geni_rs485_config;\n1910:\t\tuport-\u003ers485_supported = qcom_geni_rs485_supported;\n1911:\t\tport-\u003etx_fifo_depth = DEF_FIFO_DEPTH_WORDS;\n1912:\t\tport-\u003erx_fifo_depth = DEF_FIFO_DEPTH_WORDS;\n1913:\t\tport-\u003etx_fifo_width = DEF_FIFO_WIDTH_BITS;\n1914:\t\n1915:\t\tif (!data-\u003econsole) {\n1916:\t\t\tport-\u003erx_buf = devm_kzalloc(uport-\u003edev,\n1917:\t\t\t\t\t\t DMA_RX_BUF_SIZE, GFP_KERNEL);\n1918:\t\t\tif (!port-\u003erx_buf) {\n1919:\t\t\t\tret = -ENOMEM;\n1920:\t\t\t\tgoto error;\n1921:\t\t\t}\n1922:\t\n1923:\t\t\tport-\u003erx_dma_addr = dma_map_single(pdev-\u003edev.parent, port-\u003erx_buf,\n1924:\t\t\t\t\t\t\t DMA_RX_BUF_SIZE, DMA_FROM_DEVICE);\n1925:\t\t\tif (dma_mapping_error(pdev-\u003edev.parent, port-\u003erx_dma_addr)) {\n1926:\t\t\t\tret = -EIO;\n1927:\t\t\t\tdev_err(\u0026pdev-\u003edev, \"Failed to map RX DMA buffer: %d\\n\", ret);\n1928:\t\t\t\tgoto error;\n1929:\t\t\t}\n1930:\t\t}\n1931:\t\n1932:\t\tport-\u003ename = devm_kasprintf(uport-\u003edev, GFP_KERNEL,\n1933:\t\t\t\t\"qcom_geni_serial_%s%d\",\n1934:\t\t\t\tuart_console(uport) ? \"console\" : \"uart\", uport-\u003eline);\n1935:\t\tif (!port-\u003ename) {\n1936:\t\t\tret = -ENOMEM;\n1937:\t\t\tgoto error;\n1938:\t\t}\n1939:\t\n1940:\t\tirq = platform_get_irq(pdev, 0);\n1941:\t\tif (irq \u003c 0) {\n1942:\t\t\tret = irq;\n1943:\t\t\tgoto error;\n1944:\t\t}\n1945:\t\n"
} |
| 19/2 | 2026/09/16 08:09 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 11583 output: 38 thoughts: 78 Thoughts: Okay, let's break this down. **Diving into the Initialization Sequence** Alright, so I'm looking at this code and immediately I see two lines that pique my interest. First, the assignment: `port->se.wrapper = dev_get_drvdata(pdev->dev.parent);`. I understand what's happening here – we're grabbing driver data from the parent device, presumably for some kind of wrapper structure. Got it. Makes sense, standard practice. Next, we have `ret = port->dev_data->resources_init(&port->se);`. This line screams “initialization” to me. The `resources_init` function is the key here. It's obviously setting up resources, probably hardware or configuration, for the `port->se` structure. Now, my next move, as an expert in embedded systems and serial communication drivers, is to track down what that `resources_init` function *actually* does. Time to go hunting for its definition. I'll jump right into `qcom_geni_serial.c` since that seems like the most likely place. Let's see what kind of magic is happening within that function. |
| 20/2 | 2026/09/16 08:09 | tool | grepper |
0mArgs:{
"Expression": "resources_init",
"PathPrefix": "drivers/tty/serial/qcom_geni_serial.c"
}Results: {
"Output": "drivers/tty/serial/qcom_geni_serial.c=113=struct qcom_geni_device_data {\n--\ndrivers/tty/serial/qcom_geni_serial.c-115-\tenum geni_se_xfer_mode mode;\ndrivers/tty/serial/qcom_geni_serial.c:116:\tint (*resources_init)(struct geni_se *se);\ndrivers/tty/serial/qcom_geni_serial.c-117-\tint (*set_rate)(struct geni_se *se, unsigned long baud);\n--\ndrivers/tty/serial/qcom_geni_serial.c=1856=static int qcom_geni_serial_probe(struct platform_device *pdev)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1896-\ndrivers/tty/serial/qcom_geni_serial.c:1897:\tret = port-\u003edev_data-\u003eresources_init(\u0026port-\u003ese);\ndrivers/tty/serial/qcom_geni_serial.c-1898-\tif (ret)\n--\ndrivers/tty/serial/qcom_geni_serial.c=2114=static const struct qcom_geni_device_data qcom_geni_console_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2116-\t.mode = GENI_SE_FIFO,\ndrivers/tty/serial/qcom_geni_serial.c:2117:\t.resources_init = geni_se_resources_init,\ndrivers/tty/serial/qcom_geni_serial.c-2118-\t.set_rate = geni_serial_set_rate,\n--\ndrivers/tty/serial/qcom_geni_serial.c=2123=static const struct qcom_geni_device_data sa8255p_qcom_geni_console_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2125-\t.mode = GENI_SE_FIFO,\ndrivers/tty/serial/qcom_geni_serial.c:2126:\t.resources_init = geni_se_domain_attach,\ndrivers/tty/serial/qcom_geni_serial.c-2127-\t.set_rate = geni_se_set_perf_level,\n--\ndrivers/tty/serial/qcom_geni_serial.c=2131=static const struct qcom_geni_device_data qcom_geni_uart_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2133-\t.mode = GENI_SE_DMA,\ndrivers/tty/serial/qcom_geni_serial.c:2134:\t.resources_init = geni_se_resources_init,\ndrivers/tty/serial/qcom_geni_serial.c-2135-\t.set_rate = geni_serial_set_rate,\n--\ndrivers/tty/serial/qcom_geni_serial.c=2140=static const struct qcom_geni_device_data sa8255p_qcom_geni_uart_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2142-\t.mode = GENI_SE_DMA,\ndrivers/tty/serial/qcom_geni_serial.c:2143:\t.resources_init = geni_se_domain_attach,\ndrivers/tty/serial/qcom_geni_serial.c-2144-\t.set_rate = geni_se_set_perf_level,\n"
} |
| 21/2 | 2026/09/16 08:09 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 12877 output: 43 thoughts: 606 Thoughts: **My Assessment of the `qcom_geni_serial.c` Driver's Fuzzing Suitability** Okay, so I'm looking at `qcom_geni_serial.c`. Right off the bat, it's pretty clear this driver is for Qualcomm's GENI serial hardware, which is a platform device found on Qualcomm's ARM and ARM64 SoCs. My first thought is: can this even run on amd64, our target architecture? Let's see... the prompt emphasizes reachability, and from Section 1 & 2, I know fuzzing is limited to code that can execute in standard virtualized environments. The prompt specifies that hardware-specific code that requires physical cards not emulated in standard QEMU should not be fuzzed. Now, checking the Kconfig files: In `drivers/tty/serial/Kconfig`: ```kconfig config SERIAL_QCOM_GENI tristate "Qualcomm on-chip GENI based serial port support" depends on ARCH_QCOM || COMPILE_TEST depends on QCOM_GENI_SE select SERIAL_CORE ``` In `drivers/soc/qcom/Kconfig`: ```kconfig config QCOM_GENI_SE tristate "Qualcomm GENI Serial Engine Driver" depends on ARM64 || COMPILE_TEST default ARCH_QCOM ``` Okay, `SERIAL_QCOM_GENI` itself depends on `QCOM_GENI_SE`, and `QCOM_GENI_SE` depends on `ARM64`. `COMPILE_TEST` gives it a chance to compile on x86/amd64, but that's not the end of the story. The critical question here is whether the hardware is present in QEMU x86_64 or GCE. The answer is a firm "no." This driver specifically needs Qualcomm hardware – the GENI QUP Wrapper and Serial Engine. Standard QEMU x86_64 (or GCE) doesn't emulate that. Even if it *could* compile, the execution environment isn't correct. Furthermore, the function we are interested in is `geni_serial_set_rate`. I need to track down where this is called but it does not matter. The driver's hardware dependency makes it un-fuzzable according to the provided requirements. My conclusion is that this is structurally unreachable in the target environment and, therefore, should be excluded from fuzzing efforts. |
| 22/2 | 2026/09/16 08:10 | tool | grepper |
0mArgs:{
"Expression": "geni_serial_set_rate",
"PathPrefix": "drivers/tty/serial/qcom_geni_serial.c"
}Results: {
"Output": "drivers/tty/serial/qcom_geni_serial.c=1404=static int qcom_geni_serial_startup(struct uart_port *uport)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1440-\ndrivers/tty/serial/qcom_geni_serial.c:1441:static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)\ndrivers/tty/serial/qcom_geni_serial.c-1442-{\n--\ndrivers/tty/serial/qcom_geni_serial.c=2114=static const struct qcom_geni_device_data qcom_geni_console_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2117-\t.resources_init = geni_se_resources_init,\ndrivers/tty/serial/qcom_geni_serial.c:2118:\t.set_rate = geni_serial_set_rate,\ndrivers/tty/serial/qcom_geni_serial.c-2119-\t.power_on = geni_se_resources_activate,\n--\ndrivers/tty/serial/qcom_geni_serial.c=2131=static const struct qcom_geni_device_data qcom_geni_uart_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2134-\t.resources_init = geni_se_resources_init,\ndrivers/tty/serial/qcom_geni_serial.c:2135:\t.set_rate = geni_serial_set_rate,\ndrivers/tty/serial/qcom_geni_serial.c-2136-\t.power_on = geni_se_resources_activate,\n"
} |
| 23/2 | 2026/09/16 08:10 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 14534 output: 38 thoughts: 30 Thoughts: Here's a summary of my thought process, as requested: **Digging into the QCOM GENI Serial Driver** Okay, so I need to understand how the serial rate is being set in this QCOM GENI serial driver. The function `port->dev_data->set_rate` seems like the key here. My next step is to figure out where that function is actually *called* within `qcom_geni_serial.c`. Understanding the call sites will give me the context I need to see *when* and *why* the serial rate is being manipulated. It's the only way to effectively debug or modify the rate control logic. Let's start tracing those calls... |
| 24/2 | 2026/09/16 08:10 | tool | grepper |
0mArgs:{
"Expression": "set_rate",
"PathPrefix": "drivers/tty/serial/qcom_geni_serial.c"
}Results: {
"Output": "drivers/tty/serial/qcom_geni_serial.c=113=struct qcom_geni_device_data {\n--\ndrivers/tty/serial/qcom_geni_serial.c-116-\tint (*resources_init)(struct geni_se *se);\ndrivers/tty/serial/qcom_geni_serial.c:117:\tint (*set_rate)(struct geni_se *se, unsigned long baud);\ndrivers/tty/serial/qcom_geni_serial.c-118-\tint (*power_on)(struct geni_se *se);\n--\ndrivers/tty/serial/qcom_geni_serial.c=1404=static int qcom_geni_serial_startup(struct uart_port *uport)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1440-\ndrivers/tty/serial/qcom_geni_serial.c:1441:static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)\ndrivers/tty/serial/qcom_geni_serial.c-1442-{\n--\ndrivers/tty/serial/qcom_geni_serial.c-1476-\tport-\u003eclk_rate = clk_rate;\ndrivers/tty/serial/qcom_geni_serial.c:1477:\tdev_pm_opp_set_rate(uport-\u003edev, clk_rate);\ndrivers/tty/serial/qcom_geni_serial.c-1478-\tser_clk_cfg = SER_CLK_EN;\n--\ndrivers/tty/serial/qcom_geni_serial.c=1497=static void qcom_geni_serial_set_termios(struct uart_port *uport,\n--\ndrivers/tty/serial/qcom_geni_serial.c-1514-\ndrivers/tty/serial/qcom_geni_serial.c:1515:\tret = port-\u003edev_data-\u003eset_rate(\u0026port-\u003ese, baud);\ndrivers/tty/serial/qcom_geni_serial.c-1516-\tif (ret)\n--\ndrivers/tty/serial/qcom_geni_serial.c=2046=static int __maybe_unused qcom_geni_serial_runtime_resume(struct device *dev)\n--\ndrivers/tty/serial/qcom_geni_serial.c-2058-\tif (port-\u003ese.has_opp \u0026\u0026 port-\u003eclk_rate)\ndrivers/tty/serial/qcom_geni_serial.c:2059:\t\treturn dev_pm_opp_set_rate(uport-\u003edev, port-\u003eclk_rate);\ndrivers/tty/serial/qcom_geni_serial.c-2060-\n--\ndrivers/tty/serial/qcom_geni_serial.c=2114=static const struct qcom_geni_device_data qcom_geni_console_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2117-\t.resources_init = geni_se_resources_init,\ndrivers/tty/serial/qcom_geni_serial.c:2118:\t.set_rate = geni_serial_set_rate,\ndrivers/tty/serial/qcom_geni_serial.c-2119-\t.power_on = geni_se_resources_activate,\n--\ndrivers/tty/serial/qcom_geni_serial.c=2123=static const struct qcom_geni_device_data sa8255p_qcom_geni_console_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2126-\t.resources_init = geni_se_domain_attach,\ndrivers/tty/serial/qcom_geni_serial.c:2127:\t.set_rate = geni_se_set_perf_level,\ndrivers/tty/serial/qcom_geni_serial.c-2128-};\n--\ndrivers/tty/serial/qcom_geni_serial.c=2131=static const struct qcom_geni_device_data qcom_geni_uart_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2134-\t.resources_init = geni_se_resources_init,\ndrivers/tty/serial/qcom_geni_serial.c:2135:\t.set_rate = geni_serial_set_rate,\ndrivers/tty/serial/qcom_geni_serial.c-2136-\t.power_on = geni_se_resources_activate,\n--\ndrivers/tty/serial/qcom_geni_serial.c=2140=static const struct qcom_geni_device_data sa8255p_qcom_geni_uart_data = {\n--\ndrivers/tty/serial/qcom_geni_serial.c-2143-\t.resources_init = geni_se_domain_attach,\ndrivers/tty/serial/qcom_geni_serial.c:2144:\t.set_rate = geni_se_set_perf_level,\ndrivers/tty/serial/qcom_geni_serial.c-2145-};\n"
} |
| 25/2 | 2026/09/16 08:10 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 16066 output: 19 thoughts: 268 Thoughts: **My Analysis of the `qcom_geni_serial` Driver** Okay, so let's break this down. The `set_rate` function in this `qcom_geni_serial` module is only called when someone adjusts the terminal settings (termios) of a serial device. And *that* only happens if the device is already open. For a device to be open, it has to have gone through the probing process in `qcom_geni_serial_probe`. Makes sense. Now, what does the probe require? It needs to find a platform device that matches a specific `of_device_id` entry – essentially, a description of the hardware. The valid matches are the "qcom,geni-debug-uart" and variants. Beyond that, the probe needs a parent device, which I'm assuming is the GENI wrapper. Of course, it also needs the standard hardware resources: clock, interconnect, OPP (Operating Performance Point), interrupts, and memory-mapped I/O for the Qualcomm QUP. Right, standard stuff for a Qualcomm embedded SoC driver. So we're dealing with Qualcomm's QUP serial ports on embedded devices. Now, a quick thought: I'm interested in how the clock is set up. Let me make sure I understand the `CORE_2X_19_2_MHZ` and `CORE_2X_50_MHZ` values within the context of `include/linux/soc/qcom/geni-se.h`. Are these used anywhere else that might change the serial port behaviour? Let me cross reference those defines and see. |
| 26/2 | 2026/09/16 08:10 | tool | grepper |
0mArgs:{
"Expression": "CORE_2X_"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 706 lines.\nUse more precise expression if possible.\n\ndrivers/clk/qcom/gcc-eliza.c=2812=static struct clk_regmap *gcc_eliza_clocks[] = {\n--\ndrivers/clk/qcom/gcc-eliza.c-2876-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-eliza.c:2877:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-eliza.c-2878-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-eliza.c-2896-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-eliza.c:2897:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-eliza.c-2898-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-glymur.c=7964=static struct clk_regmap *gcc_glymur_clocks[] = {\n--\ndrivers/clk/qcom/gcc-glymur.c-8139-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-glymur.c:8140:\t[GCC_QUPV3_OOB_CORE_2X_CLK] = \u0026gcc_qupv3_oob_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-glymur.c-8141-\t[GCC_QUPV3_OOB_CORE_CLK] = \u0026gcc_qupv3_oob_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-glymur.c-8152-\t[GCC_QUPV3_OOB_TCXO_CLK] = \u0026gcc_qupv3_oob_tcxo_clk.clkr,\ndrivers/clk/qcom/gcc-glymur.c:8153:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-glymur.c-8154-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-glymur.c-8176-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-glymur.c:8177:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-glymur.c-8178-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-glymur.c-8200-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-glymur.c:8201:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-glymur.c-8202-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-hawi.c=3312=static struct clk_regmap *gcc_hawi_clocks[] = {\n--\ndrivers/clk/qcom/gcc-hawi.c-3384-\t[GCC_QUPV3_I2C_S_AHB_CLK] = \u0026gcc_qupv3_i2c_s_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-hawi.c:3385:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-hawi.c-3386-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-hawi.c-3404-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-hawi.c:3405:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-hawi.c-3406-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-hawi.c-3416-\t[GCC_QUPV3_WRAP2_S4_CLK_SRC] = \u0026gcc_qupv3_wrap2_s4_clk_src.clkr,\ndrivers/clk/qcom/gcc-hawi.c:3417:\t[GCC_QUPV3_WRAP3_CORE_2X_CLK] = \u0026gcc_qupv3_wrap3_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-hawi.c-3418-\t[GCC_QUPV3_WRAP3_CORE_CLK] = \u0026gcc_qupv3_wrap3_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-hawi.c-3432-\t[GCC_QUPV3_WRAP3_S5_CLK_SRC] = \u0026gcc_qupv3_wrap3_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-hawi.c:3433:\t[GCC_QUPV3_WRAP4_CORE_2X_CLK] = \u0026gcc_qupv3_wrap4_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-hawi.c-3434-\t[GCC_QUPV3_WRAP4_CORE_CLK] = \u0026gcc_qupv3_wrap4_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-kaanapali.c=3208=static struct clk_regmap *gcc_kaanapali_clocks[] = {\n--\ndrivers/clk/qcom/gcc-kaanapali.c-3265-\t[GCC_QUPV3_I2C_S_AHB_CLK] = \u0026gcc_qupv3_i2c_s_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c:3266:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c-3267-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-kaanapali.c-3285-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c:3286:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c-3287-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-kaanapali.c-3297-\t[GCC_QUPV3_WRAP2_S4_CLK_SRC] = \u0026gcc_qupv3_wrap2_s4_clk_src.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c:3298:\t[GCC_QUPV3_WRAP3_CORE_2X_CLK] = \u0026gcc_qupv3_wrap3_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c-3299-\t[GCC_QUPV3_WRAP3_CORE_CLK] = \u0026gcc_qupv3_wrap3_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-kaanapali.c-3314-\t[GCC_QUPV3_WRAP3_S5_CLK_SRC] = \u0026gcc_qupv3_wrap3_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c:3315:\t[GCC_QUPV3_WRAP4_CORE_2X_CLK] = \u0026gcc_qupv3_wrap4_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-kaanapali.c-3316-\t[GCC_QUPV3_WRAP4_CORE_CLK] = \u0026gcc_qupv3_wrap4_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-milos.c=2942=static struct clk_regmap *gcc_milos_clocks[] = {\n--\ndrivers/clk/qcom/gcc-milos.c-3012-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-milos.c:3013:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-milos.c-3014-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-milos.c-3030-\t[GCC_QUPV3_WRAP0_S6_CLK_SRC] = \u0026gcc_qupv3_wrap0_s6_clk_src.clkr,\ndrivers/clk/qcom/gcc-milos.c:3031:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-milos.c-3032-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-nord.c=1699=static struct clk_regmap *gcc_nord_clocks[] = {\n--\ndrivers/clk/qcom/gcc-nord.c-1781-\t[GCC_PDM_XO4_CLK] = \u0026gcc_pdm_xo4_clk.clkr,\ndrivers/clk/qcom/gcc-nord.c:1782:\t[GCC_QUPV3_WRAP3_CORE_2X_CLK] = \u0026gcc_qupv3_wrap3_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-nord.c-1783-\t[GCC_QUPV3_WRAP3_CORE_CLK] = \u0026gcc_qupv3_wrap3_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qcm2290.c=2771=static struct clk_regmap *gcc_qcm2290_clocks[] = {\n--\ndrivers/clk/qcom/gcc-qcm2290.c-2848-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-qcm2290.c:2849:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qcm2290.c-2850-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qcs615.c=2755=static struct clk_regmap *gcc_qcs615_clocks[] = {\n--\ndrivers/clk/qcom/gcc-qcs615.c-2812-\t[GCC_QSPI_CORE_CLK_SRC] = \u0026gcc_qspi_core_clk_src.clkr,\ndrivers/clk/qcom/gcc-qcs615.c:2813:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qcs615.c-2814-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qcs615.c-2826-\t[GCC_QUPV3_WRAP0_S5_CLK_SRC] = \u0026gcc_qupv3_wrap0_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-qcs615.c:2827:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qcs615.c-2828-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qcs8300.c=3324=static struct clk_regmap *gcc_qcs8300_clocks[] = {\n--\ndrivers/clk/qcom/gcc-qcs8300.c-3412-\t[GCC_QMIP_VIDEO_VCPU_AHB_CLK] = \u0026gcc_qmip_video_vcpu_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-qcs8300.c:3413:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qcs8300.c-3414-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qcs8300.c-3430-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-qcs8300.c:3431:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qcs8300.c-3432-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qcs8300.c-3448-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-qcs8300.c:3449:\t[GCC_QUPV3_WRAP3_CORE_2X_CLK] = \u0026gcc_qupv3_wrap3_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qcs8300.c-3450-\t[GCC_QUPV3_WRAP3_CORE_CLK] = \u0026gcc_qupv3_wrap3_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qdu1000.c=2447=static struct clk_regmap *gcc_qdu1000_clocks[] = {\n--\ndrivers/clk/qcom/gcc-qdu1000.c-2501-\t[GCC_QMIP_ECPRI_GSI_CLK] = \u0026gcc_qmip_ecpri_gsi_clk.clkr,\ndrivers/clk/qcom/gcc-qdu1000.c:2502:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qdu1000.c-2503-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-qdu1000.c-2519-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-qdu1000.c:2520:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-qdu1000.c-2521-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sa8775p.c=4315=static struct clk_regmap *gcc_sa8775p_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sa8775p.c-4417-\t[GCC_QMIP_VIDEO_VCPU_AHB_CLK] = \u0026gcc_qmip_video_vcpu_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c:4418:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c-4419-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sa8775p.c-4433-\t[GCC_QUPV3_WRAP0_S6_CLK_SRC] = \u0026gcc_qupv3_wrap0_s6_clk_src.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c:4434:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c-4435-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sa8775p.c-4449-\t[GCC_QUPV3_WRAP1_S6_CLK_SRC] = \u0026gcc_qupv3_wrap1_s6_clk_src.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c:4450:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c-4451-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sa8775p.c-4465-\t[GCC_QUPV3_WRAP2_S6_CLK_SRC] = \u0026gcc_qupv3_wrap2_s6_clk_src.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c:4466:\t[GCC_QUPV3_WRAP3_CORE_2X_CLK] = \u0026gcc_qupv3_wrap3_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sa8775p.c-4467-\t[GCC_QUPV3_WRAP3_CORE_CLK] = \u0026gcc_qupv3_wrap3_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sar2130p.c=2116=static struct clk_regmap *gcc_sar2130p_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sar2130p.c-2177-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sar2130p.c:2178:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sar2130p.c-2179-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sar2130p.c-2191-\t[GCC_QUPV3_WRAP0_S5_CLK_SRC] = \u0026gcc_qupv3_wrap0_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sar2130p.c:2192:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sar2130p.c-2193-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc7180.c=2246=static struct clk_regmap *gcc_sc7180_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sc7180.c-2289-\t[GCC_QSPI_CORE_CLK_SRC] = \u0026gcc_qspi_core_clk_src.clkr,\ndrivers/clk/qcom/gcc-sc7180.c:2290:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc7180.c-2291-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc7180.c-2303-\t[GCC_QUPV3_WRAP0_S5_CLK_SRC] = \u0026gcc_qupv3_wrap0_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sc7180.c:2304:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc7180.c-2305-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc7280.c=3195=static struct clk_regmap *gcc_sc7280_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sc7280.c-3259-\t[GCC_QSPI_CORE_CLK_SRC] = \u0026gcc_qspi_core_clk_src.clkr,\ndrivers/clk/qcom/gcc-sc7280.c:3260:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc7280.c-3261-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc7280.c-3277-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sc7280.c:3278:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc7280.c-3279-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc8280xp.c=6985=static struct clk_regmap *gcc_sc8280xp_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sc8280xp.c-7158-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sc8280xp.c:7159:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc8280xp.c-7160-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc8280xp.c-7178-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sc8280xp.c:7179:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc8280xp.c-7180-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sc8280xp.c-7198-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sc8280xp.c:7199:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sc8280xp.c-7200-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sdx75.c=2703=static struct clk_regmap *gcc_sdx75_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sdx75.c-2795-\t[GCC_PDM_XO4_CLK] = \u0026gcc_pdm_xo4_clk.clkr,\ndrivers/clk/qcom/gcc-sdx75.c:2796:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sdx75.c-2797-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm4450.c=2612=static struct clk_regmap *gcc_sm4450_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm4450.c-2676-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm4450.c:2677:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm4450.c-2678-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm4450.c-2688-\t[GCC_QUPV3_WRAP0_S4_CLK_SRC] = \u0026gcc_qupv3_wrap0_s4_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm4450.c:2689:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm4450.c-2690-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6115.c=3268=static struct clk_regmap *gcc_sm6115_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm6115.c-3354-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm6115.c:3355:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6115.c-3356-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6125.c=3875=static struct clk_regmap *gcc_sm6125_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm6125.c-3993-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm6125.c:3994:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6125.c-3995-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6125.c-4007-\t[GCC_QUPV3_WRAP0_S5_CLK_SRC] = \u0026gcc_qupv3_wrap0_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm6125.c:4008:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6125.c-4009-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6350.c=2361=static struct clk_regmap *gcc_sm6350_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm6350.c-2410-\t[GCC_PRNG_AHB_CLK] = \u0026gcc_prng_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm6350.c:2411:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6350.c-2412-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6350.c-2424-\t[GCC_QUPV3_WRAP0_S5_CLK_SRC] = \u0026gcc_qupv3_wrap0_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm6350.c:2425:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6350.c-2426-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6375.c=3611=static struct clk_regmap *gcc_sm6375_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm6375.c-3701-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm6375.c:3702:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6375.c-3703-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm6375.c-3715-\t[GCC_QUPV3_WRAP0_S5_CLK_SRC] = \u0026gcc_qupv3_wrap0_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm6375.c:3716:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm6375.c-3717-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm7150.c=2754=static struct clk_regmap *gcc_sm7150_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm7150.c-2807-\t[GCC_PRNG_AHB_CLK] = \u0026gcc_prng_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm7150.c:2808:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm7150.c-2809-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm7150.c-2825-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm7150.c:2826:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm7150.c-2827-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8250.c=3316=static struct clk_regmap *gcc_sm8250_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm8250.c-3393-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm8250.c:3394:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8250.c-3395-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8250.c-3411-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8250.c:3412:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8250.c-3413-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8250.c-3425-\t[GCC_QUPV3_WRAP1_S5_CLK_SRC] = \u0026gcc_qupv3_wrap1_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8250.c:3426:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8250.c-3427-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8350.c=3503=static struct clk_regmap *gcc_sm8350_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm8350.c-3567-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm8350.c:3568:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8350.c-3569-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8350.c-3585-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8350.c:3586:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8350.c-3587-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8350.c-3599-\t[GCC_QUPV3_WRAP1_S5_CLK_SRC] = \u0026gcc_qupv3_wrap1_s5_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8350.c:3600:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8350.c-3601-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8450.c=3147=static struct clk_regmap *gcc_sm8450_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm8450.c-3213-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm8450.c:3214:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8450.c-3215-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8450.c-3231-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8450.c:3232:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8450.c-3233-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8450.c-3247-\t[GCC_QUPV3_WRAP1_S6_CLK_SRC] = \u0026gcc_qupv3_wrap1_s6_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8450.c:3248:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8450.c-3249-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8550.c=3079=static struct clk_regmap *gcc_sm8550_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm8550.c-3164-\t[GCC_QUPV3_I2C_S_AHB_CLK] = \u0026gcc_qupv3_i2c_s_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm8550.c:3165:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8550.c-3166-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8550.c-3182-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8550.c:3183:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8550.c-3184-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8650.c=3512=static struct clk_regmap *gcc_sm8650_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm8650.c-3600-\t[GCC_QUPV3_I2C_S_AHB_CLK] = \u0026gcc_qupv3_i2c_s_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm8650.c:3601:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8650.c-3602-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8650.c-3620-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8650.c:3621:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8650.c-3622-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8650.c-3641-\t[GCC_QUPV3_WRAP2_S7_CLK_SRC] = \u0026gcc_qupv3_wrap2_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8650.c:3642:\t[GCC_QUPV3_WRAP3_CORE_2X_CLK] = \u0026gcc_qupv3_wrap3_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8650.c-3643-\t[GCC_QUPV3_WRAP3_CORE_CLK] = \u0026gcc_qupv3_wrap3_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8750.c=2959=static struct clk_regmap *gcc_sm8750_clocks[] = {\n--\ndrivers/clk/qcom/gcc-sm8750.c-3033-\t[GCC_QUPV3_I2C_S_AHB_CLK] = \u0026gcc_qupv3_i2c_s_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-sm8750.c:3034:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8750.c-3035-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-sm8750.c-3053-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-sm8750.c:3054:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-sm8750.c-3055-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-x1e80100.c=6871=static struct clk_regmap *gcc_x1e80100_clocks[] = {\n--\ndrivers/clk/qcom/gcc-x1e80100.c-7029-\t[GCC_QMIP_VIDEO_VCODEC_AHB_CLK] = \u0026gcc_qmip_video_vcodec_ahb_clk.clkr,\ndrivers/clk/qcom/gcc-x1e80100.c:7030:\t[GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-x1e80100.c-7031-\t[GCC_QUPV3_WRAP0_CORE_CLK] = \u0026gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-x1e80100.c-7051-\t[GCC_QUPV3_WRAP0_S7_CLK_SRC] = \u0026gcc_qupv3_wrap0_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-x1e80100.c:7052:\t[GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-x1e80100.c-7053-\t[GCC_QUPV3_WRAP1_CORE_CLK] = \u0026gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/clk/qcom/gcc-x1e80100.c-7073-\t[GCC_QUPV3_WRAP1_S7_CLK_SRC] = \u0026gcc_qupv3_wrap1_s7_clk_src.clkr,\ndrivers/clk/qcom/gcc-x1e80100.c:7074:\t[GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/gcc-x1e80100.c-7075-\t[GCC_QUPV3_WRAP2_CORE_CLK] = \u0026gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/lpass-gfm-sm8250.c=89=static struct clk_gfm lpass_gfm_tx_npl = {\n--\ndrivers/clk/qcom/lpass-gfm-sm8250.c-101-\t\t\t\t.index = 1,\ndrivers/clk/qcom/lpass-gfm-sm8250.c:102:\t\t\t\t.fw_name = \"LPASS_CLK_ID_VA_CORE_2X_MCLK\",\ndrivers/clk/qcom/lpass-gfm-sm8250.c-103-\t\t\t},\n--\ndrivers/clk/qcom/negcc-nord.c=1802=static struct clk_regmap *ne_gcc_nord_clocks[] = {\n--\ndrivers/clk/qcom/negcc-nord.c-1823-\t[NE_GCC_GPU_2_SMMU_VOTE_CLK] = \u0026ne_gcc_gpu_2_smmu_vote_clk.clkr,\ndrivers/clk/qcom/negcc-nord.c:1824:\t[NE_GCC_QUPV3_WRAP2_CORE_2X_CLK] = \u0026ne_gcc_qupv3_wrap2_core_2x_clk.clkr,\ndrivers/clk/qcom/negcc-nord.c-1825-\t[NE_GCC_QUPV3_WRAP2_CORE_CLK] = \u0026ne_gcc_qupv3_wrap2_core_clk.clkr,\n--\ndrivers/clk/qcom/segcc-nord.c=1453=static struct clk_regmap *se_gcc_nord_clocks[] = {\n--\ndrivers/clk/qcom/segcc-nord.c-1494-\t[SE_GCC_MMU_2_TCU_VOTE_CLK] = \u0026se_gcc_mmu_2_tcu_vote_clk.clkr,\ndrivers/clk/qcom/segcc-nord.c:1495:\t[SE_GCC_QUPV3_WRAP0_CORE_2X_CLK] = \u0026se_gcc_qupv3_wrap0_core_2x_clk.clkr,\ndrivers/clk/qcom/segcc-nord.c-1496-\t[SE_GCC_QUPV3_WRAP0_CORE_CLK] = \u0026se_gcc_qupv3_wrap0_core_clk.clkr,\n--\ndrivers/clk/qcom/segcc-nord.c-1512-\t[SE_GCC_QUPV3_WRAP0_S_AHB_CLK] = \u0026se_gcc_qupv3_wrap0_s_ahb_clk.clkr,\ndrivers/clk/qcom/segcc-nord.c:1513:\t[SE_GCC_QUPV3_WRAP1_CORE_2X_CLK] = \u0026se_gcc_qupv3_wrap1_core_2x_clk.clkr,\ndrivers/clk/qcom/segcc-nord.c-1514-\t[SE_GCC_QUPV3_WRAP1_CORE_CLK] = \u0026se_gcc_qupv3_wrap1_core_clk.clkr,\n--\ndrivers/tty/serial/qcom_geni_serial.c=1441=static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1484-\t */\ndrivers/tty/serial/qcom_geni_serial.c:1485:\tavg_bw_core = baud \u003e 115200 ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;\ndrivers/tty/serial/qcom_geni_serial.c-1486-\tport-\u003ese.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(avg_bw_core);\n--\ninclude/dt-bindings/clock/qcom,eliza-gcc.h-80-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t\t70\ninclude/dt-bindings/clock/qcom,eliza-gcc.h:81:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t71\ninclude/dt-bindings/clock/qcom,eliza-gcc.h-82-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t72\n--\ninclude/dt-bindings/clock/qcom,eliza-gcc.h-100-#define GCC_QUPV3_WRAP1_S7_CLK_SRC\t\t\t\t90\ninclude/dt-bindings/clock/qcom,eliza-gcc.h:101:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t91\ninclude/dt-bindings/clock/qcom,eliza-gcc.h-102-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t92\n--\ninclude/dt-bindings/clock/qcom,gcc-qcm2290.h-111-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t101\ninclude/dt-bindings/clock/qcom,gcc-qcm2290.h:112:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t102\ninclude/dt-bindings/clock/qcom,gcc-qcm2290.h-113-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t103\n--\ninclude/dt-bindings/clock/qcom,gcc-sc7180.h-65-#define GCC_QSPI_CORE_CLK_SRC\t\t\t\t\t55\ninclude/dt-bindings/clock/qcom,gcc-sc7180.h:66:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t\t56\ninclude/dt-bindings/clock/qcom,gcc-sc7180.h-67-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t\t57\n--\ninclude/dt-bindings/clock/qcom,gcc-sc7180.h-79-#define GCC_QUPV3_WRAP0_S5_CLK_SRC\t\t\t\t69\ninclude/dt-bindings/clock/qcom,gcc-sc7180.h:80:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t70\ninclude/dt-bindings/clock/qcom,gcc-sc7180.h-81-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t71\n--\ninclude/dt-bindings/clock/qcom,gcc-sc7280.h-77-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t67\ninclude/dt-bindings/clock/qcom,gcc-sc7280.h:78:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t68\ninclude/dt-bindings/clock/qcom,gcc-sc7280.h-79-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t69\n--\ninclude/dt-bindings/clock/qcom,gcc-sc7280.h-95-#define GCC_QUPV3_WRAP0_S7_CLK_SRC\t\t\t85\ninclude/dt-bindings/clock/qcom,gcc-sc7280.h:96:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t86\ninclude/dt-bindings/clock/qcom,gcc-sc7280.h-97-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t87\n--\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h-188-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t177\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h:189:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t178\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h-190-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t179\n--\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h-208-#define GCC_QUPV3_WRAP0_S7_CLK_SRC\t\t\t197\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h:209:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t198\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h-210-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t199\n--\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h-228-#define GCC_QUPV3_WRAP1_S7_CLK_SRC\t\t\t217\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h:229:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t218\ninclude/dt-bindings/clock/qcom,gcc-sc8280xp.h-230-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t219\n--\ninclude/dt-bindings/clock/qcom,gcc-sm6115.h-97-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t\t89\ninclude/dt-bindings/clock/qcom,gcc-sm6115.h:98:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t\t90\ninclude/dt-bindings/clock/qcom,gcc-sm6115.h-99-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t\t91\n--\ninclude/dt-bindings/clock/qcom,gcc-sm6125.h-139-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t130\ninclude/dt-bindings/clock/qcom,gcc-sm6125.h:140:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t131\ninclude/dt-bindings/clock/qcom,gcc-sm6125.h-141-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t132\n--\ninclude/dt-bindings/clock/qcom,gcc-sm6125.h-153-#define GCC_QUPV3_WRAP0_S5_CLK_SRC\t\t144\ninclude/dt-bindings/clock/qcom,gcc-sm6125.h:154:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t145\ninclude/dt-bindings/clock/qcom,gcc-sm6125.h-155-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t146\n--\ninclude/dt-bindings/clock/qcom,gcc-sm6350.h-79-#define GCC_PRNG_AHB_CLK\t\t\t68\ninclude/dt-bindings/clock/qcom,gcc-sm6350.h:80:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t69\ninclude/dt-bindings/clock/qcom,gcc-sm6350.h-81-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t70\n--\ninclude/dt-bindings/clock/qcom,gcc-sm6350.h-93-#define GCC_QUPV3_WRAP0_S5_CLK_SRC\t\t82\ninclude/dt-bindings/clock/qcom,gcc-sm6350.h:94:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t83\ninclude/dt-bindings/clock/qcom,gcc-sm6350.h-95-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t84\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h-94-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t\t84\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h:95:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t\t85\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h-96-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t\t86\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h-112-#define GCC_QUPV3_WRAP0_S7_CLK_SRC\t\t\t\t102\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h:113:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t103\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h-114-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t104\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h-126-#define GCC_QUPV3_WRAP1_S5_CLK_SRC\t\t\t\t116\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h:127:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t117\ninclude/dt-bindings/clock/qcom,gcc-sm8250.h-128-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t118\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h-86-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t\t74\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h:87:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t\t75\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h-88-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t\t76\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h-104-#define GCC_QUPV3_WRAP0_S7_CLK_SRC\t\t\t\t92\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h:105:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t93\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h-106-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t94\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h-118-#define GCC_QUPV3_WRAP1_S5_CLK_SRC\t\t\t\t106\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h:119:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t107\ninclude/dt-bindings/clock/qcom,gcc-sm8350.h-120-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t108\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h-95-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t\t83\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h:96:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t\t84\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h-97-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t\t85\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h-113-#define GCC_QUPV3_WRAP0_S7_CLK_SRC\t\t\t\t101\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h:114:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t102\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h-115-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t103\n--\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h-129-#define GCC_QUPV3_WRAP1_S6_CLK_SRC\t\t\t\t117\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h:130:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t118\ninclude/dt-bindings/clock/qcom,gcc-sm8450.h-131-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t119\n--\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-189-#define GCC_QMIP_VIDEO_VCODEC_AHB_CLK\t\t\t\t179\ninclude/dt-bindings/clock/qcom,glymur-gcc.h:190:#define GCC_QUPV3_OOB_CORE_2X_CLK\t\t\t\t180\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-191-#define GCC_QUPV3_OOB_CORE_CLK\t\t\t\t\t181\n--\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-202-#define GCC_QUPV3_OOB_TCXO_CLK\t\t\t\t\t192\ninclude/dt-bindings/clock/qcom,glymur-gcc.h:203:#define GCC_QUPV3_WRAP0_CORE_2X_CLK\t\t\t\t193\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-204-#define GCC_QUPV3_WRAP0_CORE_CLK\t\t\t\t194\n--\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-226-#define GCC_QUPV3_WRAP0_S7_CLK_SRC\t\t\t\t216\ninclude/dt-bindings/clock/qcom,glymur-gcc.h:227:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t217\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-228-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t218\n--\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-250-#define GCC_QUPV3_WRAP1_S7_CLK_SRC\t\t\t\t240\ninclude/dt-bindings/clock/qcom,glymur-gcc.h:251:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t241\ninclude/dt-bindings/clock/qcom,glymur-gcc.h-252-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t242\n--\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-93-#define GCC_QUPV3_I2C_S_AHB_CLK\t\t\t\t\t83\ninclude/dt-bindings/clock/qcom,hawi-gcc.h:94:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t84\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-95-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t85\n--\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-113-#define GCC_QUPV3_WRAP1_S7_CLK_SRC\t\t\t\t103\ninclude/dt-bindings/clock/qcom,hawi-gcc.h:114:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t104\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-115-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t105\n--\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-125-#define GCC_QUPV3_WRAP2_S4_CLK_SRC\t\t\t\t115\ninclude/dt-bindings/clock/qcom,hawi-gcc.h:126:#define GCC_QUPV3_WRAP3_CORE_2X_CLK\t\t\t\t116\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-127-#define GCC_QUPV3_WRAP3_CORE_CLK\t\t\t\t117\n--\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-141-#define GCC_QUPV3_WRAP3_S5_CLK_SRC\t\t\t\t131\ninclude/dt-bindings/clock/qcom,hawi-gcc.h:142:#define GCC_QUPV3_WRAP4_CORE_2X_CLK\t\t\t\t132\ninclude/dt-bindings/clock/qcom,hawi-gcc.h-143-#define GCC_QUPV3_WRAP4_CORE_CLK\t\t\t\t133\n--\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h-77-#define GCC_QUPV3_I2C_S_AHB_CLK\t\t\t\t\t67\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h:78:#define GCC_QUPV3_WRAP1_CORE_2X_CLK\t\t\t\t68\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h-79-#define GCC_QUPV3_WRAP1_CORE_CLK\t\t\t\t69\n--\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h-97-#define GCC_QUPV3_WRAP1_S7_CLK_SRC\t\t\t\t87\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h:98:#define GCC_QUPV3_WRAP2_CORE_2X_CLK\t\t\t\t88\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h-99-#define GCC_QUPV3_WRAP2_CORE_CLK\t\t\t\t89\n--\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h-109-#define GCC_QUPV3_WRAP2_S4_CLK_SRC\t\t\t\t99\ninclude/dt-bindings/clock/qcom,kaanapali-gcc.h:110:#define GCC_QUPV3_WRAP3_CORE_2X_CLK\t\t\t\t100\n\n"
} |
| 27/2 | 2026/09/16 08:10 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 36249 output: 26 thoughts: 79 Thoughts: Here's my take on those thoughts: **Investigating GENI-SE Clock Configuration** Okay, so I see these clock definitions, `CORE_2X_50_MHZ` and `CORE_2X_19_2_MHZ`, tucked away in `include/linux/soc/qcom/geni-se.h`. That's where they're defined, but I need to know *where* they're actually *used* in the codebase. Clock definitions are critical, so I want a comprehensive understanding of how they are leveraged. My immediate action is to perform a repository-wide grep for `CORE_2X_19_2_MHZ`. That should give me a list of all instances where that specific frequency is referenced, which will illuminate the different modules and subsystems that are configured for, or depend upon, that clock. This is the first step towards understanding the clocking scheme. |
| 28/2 | 2026/09/16 08:10 | tool | grepper |
0mArgs:{
"Expression": "CORE_2X_19_2_MHZ"
}Results: {
"Output": "drivers/tty/serial/qcom_geni_serial.c=1441=static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1484-\t */\ndrivers/tty/serial/qcom_geni_serial.c:1485:\tavg_bw_core = baud \u003e 115200 ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;\ndrivers/tty/serial/qcom_geni_serial.c-1486-\tport-\u003ese.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(avg_bw_core);\n--\ninclude/linux/soc/qcom/geni-se.h=70=struct geni_se {\n--\ninclude/linux/soc/qcom/geni-se.h-353- */\ninclude/linux/soc/qcom/geni-se.h:354:#define CORE_2X_19_2_MHZ\t\t9600000\ninclude/linux/soc/qcom/geni-se.h-355-#define CORE_2X_50_MHZ\t\t\t25000000\n"
} |
| 29/2 | 2026/09/16 08:10 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 36884 output: 24 thoughts: 47 Thoughts: Okay, here's my interpretation of those thoughts, summarized from my perspective as a specialist in this domain: **My Immediate Observations on Clock Configuration** Alright, so `CORE_2X_19_2_MHZ` is *exclusively* used within `qcom_geni_serial.c`. That's a very specific usage case. We should flag that as a potential area for optimization or careful consideration, as that's a *very* limited scope of use. Are there any dependencies? Could we refactor that without affecting other sections? And the big question now becomes, what about `CORE_2X_50_MHZ`? Is this also limited in use? Does it appear elsewhere in our code base? Is there a reason it wasn't used in that same file? This is a crucial next step, as it's imperative to determine the scope of this signal's usage and if there are any collisions or misinterpretations of the clock speed. We need to follow this up immediately to have any hope of understanding the impact. |
| 30/2 | 2026/09/16 08:10 | tool | grepper |
0mArgs:{
"Expression": "CORE_2X_50_MHZ"
}Results: {
"Output": "drivers/tty/serial/qcom_geni_serial.c=1441=static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)\n--\ndrivers/tty/serial/qcom_geni_serial.c-1484-\t */\ndrivers/tty/serial/qcom_geni_serial.c:1485:\tavg_bw_core = baud \u003e 115200 ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;\ndrivers/tty/serial/qcom_geni_serial.c-1486-\tport-\u003ese.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(avg_bw_core);\n--\ninclude/linux/soc/qcom/geni-se.h=70=struct geni_se {\n--\ninclude/linux/soc/qcom/geni-se.h-354-#define CORE_2X_19_2_MHZ\t\t9600000\ninclude/linux/soc/qcom/geni-se.h:355:#define CORE_2X_50_MHZ\t\t\t25000000\ninclude/linux/soc/qcom/geni-se.h-356-\n"
} |
| 31/2 | 2026/09/16 08:10 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 37512 output: 140 thoughts: 685 Thoughts: **My Assessment: Not Worth Fuzzing** Okay, let's break this down. The commit only touches `qcom_geni_serial.c` and `geni-se.h`. Specifically, the change is in `geni_serial_set_rate`. I see the target architecture is amd64, which is a key piece of information. Now, my initial thought is, this is a platform driver. It's for Qualcomm SoCs, which are ARM/ARM64. Section 2 of the fuzzing instructions is clear: Reachability is key. If the code *cannot* execute in a standard virtualized environment (QEMU/GCE), we don't fuzz it. Looking at `qcom_geni_serial.c`, this is a Qualcomm GENI serial driver. It depends on very specific Qualcomm hardware, GENI interconnects, and clocks. This isn't something that's emulated in a standard amd64 QEMU environment. Even *on* ARM64, you'd need the Qualcomm hardware. It's not generic serial hardware. Therefore, because the target is amd64 and the driver requires Qualcomm-specific hardware not emulated in that environment, it's structurally unreachable. No amount of fuzzing will expose anything in this case. I've confirmed my initial assessment. `WorthFuzzing` is `false`, `FocusSymbols` and `EnableConfigs` are empty. The reasoning, in summary: the modified code is specific to Qualcomm SoCs (ARM/ARM64), requires specific hardware not emulated on amd64, and is therefore unreachable on the target architecture. The parameters are consistent, and this is ready for `set-results`. |
| 32/2 | 2026/09/16 08:10 | tool | set-results |
0mArgs:{
"EnableConfigs": [],
"FocusSymbols": [],
"Reasoning": "The patch modifies geni_serial_set_rate() in drivers/tty/serial/qcom_geni_serial.c and clock vote macro definitions in include/linux/soc/qcom/geni-se.h. This driver is dedicated to Qualcomm GENI Serial Engine hardware present exclusively on Qualcomm ARM/ARM64 SoCs. On the target architecture (amd64), this hardware is neither present nor emulated in standard virtualized environments (QEMU/GCE), making the modified code structurally unreachable.",
"WorthFuzzing": false
}Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies geni_serial_set_rate() in drivers/tty/serial/qcom_geni_serial.c and clock vote macro definitions in include/linux/soc/qcom/geni-se.h. This driver is dedicated to Qualcomm GENI Serial Engine hardware present exclusively on Qualcomm ARM/ARM64 SoCs. On the target architecture (amd64), this hardware is neither present nor emulated in standard virtualized environments (QEMU/GCE), making the modified code structurally unreachable.",
"WorthFuzzing": false
} |
| 33/1 | 2026/09/16 08:10 | action | If |
0mArgs:{
"WorthFuzzing": false
}Results: null |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|