AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The modified function `ucsi_displayport_enter` is part of the UCSI (USB Type-C Connector System Software Interface) DisplayPort alternate mode driver. UCSI drivers (such as ucsi_acpi, ucsi_ccg, cros_ec_ucsi, and ucsi_stm32g0) require physical platform hardware (such as physical ACPI PPM devices, ChromeOS EC, or external I2C Type-C controllers) that are not emulated in standard virtualized fuzzing environments (QEMU or GCE). Because there is no software emulation or mock driver for UCSI, the modified code is structurally unreachable during fuzzing.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 4ca8974368a792bb757c49e63d1c02338479db3f\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Sep 18 20:22:35 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/usb/typec/ucsi/displayport.c b/drivers/usb/typec/ucsi/displayport.c\nindex 8d2032d0762ca..572da7bbd29c7 100644\n--- a/drivers/usb/typec/ucsi/displayport.c\n+++ b/drivers/usb/typec/ucsi/displayport.c\n@@ -71,11 +71,14 @@ static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\n \tif (ret \u003c 0) {\n \t\tif (ucsi-\u003eversion \u003e 0x0100)\n \t\t\tgoto err_unlock;\n-\t\tcur = 0xff;\n \t}\n \n-\tif (cur \u003c UCSI_MAX_ALTMODES) {\n-\t\tret = dp-\u003econ-\u003eport_altmode[cur] == alt ? 0 : -EBUSY;\n+\tif (cur != 0xff) {\n+\t\tif (cur \u003c UCSI_MAX_ALTMODES)\n+\t\t\tret = dp-\u003econ-\u003eport_altmode[cur] == alt ? 0 : -EBUSY;\n+\t\telse\n+\t\t\tret = -EINVAL;\n+\n \t\tgoto err_unlock;\n \t}\n \n"
}

core

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The modified function `ucsi_displayport_enter` is part of the UCSI (USB Type-C Connector System Software Interface) DisplayPort alternate mode driver. UCSI drivers (such as ucsi_acpi, ucsi_ccg, cros_ec_ucsi, and ucsi_stm32g0) require physical platform hardware (such as physical ACPI PPM devices, ChromeOS EC, or external I2C Type-C controllers) that are not emulated in standard virtualized fuzzing environments (QEMU or GCE). Because there is no software emulation or mock driver for UCSI, the modified code is structurally unreachable during fuzzing.",
  "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 4ca8974368a792bb757c49e63d1c02338479db3f
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Sep 18 20:22:35 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/usb/typec/ucsi/displayport.c b/drivers/usb/typec/ucsi/displayport.c
index 8d2032d0762ca..572da7bbd29c7 100644
--- a/drivers/usb/typec/ucsi/displayport.c
+++ b/drivers/usb/typec/ucsi/displayport.c
@@ -71,11 +71,14 @@ static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)
 	if (ret < 0) {
 		if (ucsi->version > 0x0100)
 			goto err_unlock;
-		cur = 0xff;
 	}
 
-	if (cur < UCSI_MAX_ALTMODES) {
-		ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY;
+	if (cur != 0xff) {
+		if (cur < UCSI_MAX_ALTMODES)
+			ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY;
+		else
+			ret = -EINVAL;
+
 		goto err_unlock;
 	}
 

gemini-3.8-flash

null

null

							input: 2991
							output: 41
							thoughts: 484
						

**Fuzzing Evaluation: A Linux Kernel Patch**

Okay, so I've got a Linux kernel patch here that needs a fuzzing assessment. It looks like the request is straightforward – a code review and fuzzing triage task, nothing malicious. The patch's severity is classified as "Benign / Defensive / Quality assurance," so that fits perfectly within the scope of what we should be doing.

My initial thought is, "Yes, let's do this!"

Now, let's dive into the patch itself. I see a `diff` showing changes in `drivers/usb/typec/ucsi/displayport.c`. Seems like a fix related to the DisplayPort alternate mode within the UCSI driver.  I'm familiar with this area, it's pretty intricate.

To properly evaluate if this is a good candidate for fuzzing with syzkaller, I need a clearer picture. I can't just look at the code snippet. I need to understand its context. I need to know how this driver is structured, what other drivers or hardware interact with it, what configurations are required, and, most importantly, how reachable the code is.

My first step is to use the tools at my disposal. I need to pull up `drivers/usb/typec/ucsi/displayport.c` and begin to investigate how it is used and the code surrounding it. I'll reach for either `grepper` or `read-file` to get a broader understanding. This will give me the insights I need to decide if syzkaller is the right tool and if this patch introduces any new areas of concern.

{
  "File": "drivers/usb/typec/ucsi/displayport.c",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t// SPDX-License-Identifier: GPL-2.0\n   2:\t/*\n   3:\t * UCSI DisplayPort Alternate Mode Support\n   4:\t *\n   5:\t * Copyright (C) 2018, Intel Corporation\n   6:\t * Author: Heikki Krogerus \u003cheikki.krogerus@linux.intel.com\u003e\n   7:\t */\n   8:\t\n   9:\t#include \u003clinux/usb/typec_dp.h\u003e\n  10:\t#include \u003clinux/usb/pd_vdo.h\u003e\n  11:\t\n  12:\t#include \"ucsi.h\"\n  13:\t\n  14:\t#define UCSI_CMD_SET_NEW_CAM(_con_num_, _enter_, _cam_, _am_)\t\t\\\n  15:\t\t (UCSI_SET_NEW_CAM | ((_con_num_) \u003c\u003c 16) | ((_enter_) \u003c\u003c 23) |\t\\\n  16:\t\t  ((_cam_) \u003c\u003c 24) | ((u64)(_am_) \u003c\u003c 32))\n  17:\t\n  18:\tstruct ucsi_dp {\n  19:\t\tstruct typec_displayport_data data;\n  20:\t\tstruct ucsi_connector *con;\n  21:\t\tstruct typec_altmode *alt;\n  22:\t\tstruct work_struct work;\n  23:\t\tint offset;\n  24:\t\n  25:\t\tbool override;\n  26:\t\tbool initialized;\n  27:\t\n  28:\t\tu32 header;\n  29:\t\tu32 *vdo_data;\n  30:\t\tu8 vdo_size;\n  31:\t};\n  32:\t\n  33:\t/*\n  34:\t * Note. Alternate mode control is optional feature in UCSI. It means that even\n  35:\t * if the system supports alternate modes, the OS may not be aware of them.\n  36:\t *\n  37:\t * In most cases however, the OS will be able to see the supported alternate\n  38:\t * modes, but it may still not be able to configure them, not even enter or exit\n  39:\t * them. That is because UCSI defines alt mode details and alt mode \"overriding\"\n  40:\t * as separate options.\n  41:\t *\n  42:\t * In case alt mode details are supported, but overriding is not, the driver\n  43:\t * will still display the supported pin assignments and configuration, but any\n  44:\t * changes the user attempts to do will lead into failure with return value of\n  45:\t * -EOPNOTSUPP.\n  46:\t */\n  47:\t\n  48:\tstatic int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\n  49:\t{\n  50:\t\tstruct ucsi_dp *dp = typec_altmode_get_drvdata(alt);\n  51:\t\tstruct ucsi *ucsi = dp-\u003econ-\u003eucsi;\n  52:\t\tint svdm_version;\n  53:\t\tu64 command;\n  54:\t\tu8 cur = 0;\n  55:\t\tint ret;\n  56:\t\n  57:\t\tif (!ucsi_con_mutex_lock(dp-\u003econ))\n  58:\t\t\treturn -ENOTCONN;\n  59:\t\n  60:\t\tif (!dp-\u003eoverride \u0026\u0026 dp-\u003einitialized) {\n  61:\t\t\tconst struct typec_altmode *p = typec_altmode_get_partner(alt);\n  62:\t\n  63:\t\t\tdev_warn(\u0026p-\u003edev,\n  64:\t\t\t\t \"firmware doesn't support alternate mode overriding\\n\");\n  65:\t\t\tret = -EOPNOTSUPP;\n  66:\t\t\tgoto err_unlock;\n  67:\t\t}\n  68:\t\n  69:\t\tcommand = UCSI_GET_CURRENT_CAM | UCSI_CONNECTOR_NUMBER(dp-\u003econ-\u003enum);\n  70:\t\tret = ucsi_send_command(ucsi, command, \u0026cur, sizeof(cur));\n  71:\t\tif (ret \u003c 0) {\n  72:\t\t\tif (ucsi-\u003eversion \u003e 0x0100)\n  73:\t\t\t\tgoto err_unlock;\n  74:\t\t}\n  75:\t\n  76:\t\tif (cur != 0xff) {\n  77:\t\t\tif (cur \u003c UCSI_MAX_ALTMODES)\n  78:\t\t\t\tret = dp-\u003econ-\u003eport_altmode[cur] == alt ? 0 : -EBUSY;\n  79:\t\t\telse\n  80:\t\t\t\tret = -EINVAL;\n  81:\t\n  82:\t\t\tgoto err_unlock;\n  83:\t\t}\n  84:\t\n  85:\t\t/*\n  86:\t\t * We can't send the New CAM command yet to the PPM as it needs the\n  87:\t\t * configuration value as well. Pretending that we have now entered the\n  88:\t\t * mode, and letting the alt mode driver continue.\n  89:\t\t */\n  90:\t\n  91:\t\tsvdm_version = typec_altmode_get_svdm_version(alt);\n  92:\t\tif (svdm_version \u003c 0) {\n  93:\t\t\tret = svdm_version;\n  94:\t\t\tgoto err_unlock;\n  95:\t\t}\n  96:\t\n  97:\t\tdp-\u003eheader = VDO(USB_TYPEC_DP_SID, 1, svdm_version, CMD_ENTER_MODE);\n  98:\t\tdp-\u003eheader |= VDO_OPOS(USB_TYPEC_DP_MODE);\n  99:\t\tdp-\u003eheader |= VDO_CMDT(CMDT_RSP_ACK);\n 100:\t\n"
}

gemini-3.8-flash

null

null

							input: 5331
							output: 36
							thoughts: 41
						

Okay, let's break this down.

**Investigating the UCSI and `ucsi_displayport_enter` Function**

Right, so I need to understand the relationship between the UCSI (USB Type-C Connector System Software Interface) and the `ucsi_displayport_enter` function. First, I need to figure out *what* the UCSI is in this context. Is it a driver, a protocol, a specific piece of hardware? And crucially, how is that `ucsi_displayport_enter` function being invoked? Is it a call from another part of the system, a hardware interrupt, something else entirely? The calling context will tell me a lot about its purpose.

To get started, I'm going to track down where `ucsi_displayport_enter` is actually registered within the system. Where does the kernel know about it? Is it part of the DisplayPort stack, the USB stack, or somewhere else? Finding its registration point will reveal its place in the overall architecture and help me to see how it fits in with the UCSI.

{
  "Expression": "ucsi_displayport_enter",
  "PathPrefix": "drivers/usb/typec/ucsi"
}

{
  "Output": "drivers/usb/typec/ucsi/displayport.c=18=struct ucsi_dp {\n--\ndrivers/usb/typec/ucsi/displayport.c-47-\ndrivers/usb/typec/ucsi/displayport.c:48:static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\ndrivers/usb/typec/ucsi/displayport.c-49-{\n--\ndrivers/usb/typec/ucsi/displayport.c=276=static const struct typec_altmode_ops ucsi_displayport_ops = {\ndrivers/usb/typec/ucsi/displayport.c:277:\t.enter = ucsi_displayport_enter,\ndrivers/usb/typec/ucsi/displayport.c-278-\t.exit = ucsi_displayport_exit,\n"
}

gemini-3.8-flash

null

null

							input: 5868
							output: 29
							thoughts: 19
						

Okay, here's my take on those thoughts, framed as my own:

**Analyzing the `typec_altmode_ops` Calls**

Alright, let's dive in. I need to figure out how `enter` is being utilized within `typec_altmode_ops`. Understanding the calls to this function is key to grasping the overall flow and interaction of this particular subsystem. I need to trace its path and see how it fits into the larger picture of altmode operation. Where and why is it being invoked? What's the context? Answering these questions will unlock the next piece of this puzzle. Let's start digging.

{
  "Expression": "-\u003eenter\\(",
  "PathPrefix": "drivers/usb/typec"
}

{
  "Output": "drivers/usb/typec/bus.c=126=int typec_altmode_enter(struct typec_altmode *adev, u32 *vdo)\n--\ndrivers/usb/typec/bus.c-146-\t/* Enter Mode */\ndrivers/usb/typec/bus.c:147:\treturn pdev-\u003eops-\u003eenter(pdev, vdo);\ndrivers/usb/typec/bus.c-148-}\n--\ndrivers/usb/typec/bus.c=259=int typec_cable_altmode_enter(struct typec_altmode *adev, enum typec_plug_index sop, u32 *vdo)\n--\ndrivers/usb/typec/bus.c-277-\ndrivers/usb/typec/bus.c:278:\treturn pdev-\u003ecable_ops-\u003eenter(pdev, sop, vdo);\ndrivers/usb/typec/bus.c-279-}\n"
}

gemini-3.8-flash

null

null

							input: 6298
							output: 33
							thoughts: 15
						

Okay, here's my summary, taking the perspective of someone familiar with embedded systems and USB Type-C:

**Diving into the `typec_altmode_enter` Function**

Alright, let's get down to brass tacks. I need to understand the execution path that leads to `typec_altmode_enter`. I'm going to start by tracing the calls to that function. My assumption is that, given the name, it's responsible for the negotiation and activation of an Alternate Mode over a USB Type-C connection. Things I'll be looking for include the conditions that trigger this call, what kind of data is passed in (port, device, protocol information) and the implications for the system afterwards. I'll need to figure out what drivers or modules are involved and how they interact to support this Alt Mode transition. This will likely involve looking at the USB Power Delivery (PD) state machine and the Role Swap process, too. Knowing the context of the call is critical for debugging, optimisation, or just general systems understanding.

{
  "Expression": "typec_altmode_enter",
  "PathPrefix": "drivers/usb/typec"
}

{
  "Output": "drivers/usb/typec/altmodes/displayport.c=265=static void dp_altmode_work(struct work_struct *work)\n--\ndrivers/usb/typec/altmodes/displayport.c-276-\tcase DP_STATE_ENTER:\ndrivers/usb/typec/altmodes/displayport.c:277:\t\tret = typec_altmode_enter(dp-\u003ealt, NULL);\ndrivers/usb/typec/altmodes/displayport.c-278-\t\tif (ret \u0026\u0026 ret != -EBUSY)\n--\ndrivers/usb/typec/altmodes/displayport.c=504=static int dp_altmode_activate(struct typec_altmode *alt, int activate)\n--\ndrivers/usb/typec/altmodes/displayport.c-518-\t\t}\ndrivers/usb/typec/altmodes/displayport.c:519:\t\treturn typec_altmode_enter(alt, NULL);\ndrivers/usb/typec/altmodes/displayport.c-520-\t} else {\n--\ndrivers/usb/typec/altmodes/thunderbolt.c=40=static int tbt_enter_mode(struct tbt_altmode *tbt)\ndrivers/usb/typec/altmodes/thunderbolt.c-41-{\ndrivers/usb/typec/altmodes/thunderbolt.c:42:\treturn typec_altmode_enter(tbt-\u003ealt, \u0026tbt-\u003eenter_vdo);\ndrivers/usb/typec/altmodes/thunderbolt.c-43-}\n--\ndrivers/usb/typec/bus.c=114=EXPORT_SYMBOL_GPL(typec_altmode_notify);\n--\ndrivers/usb/typec/bus.c-116-/**\ndrivers/usb/typec/bus.c:117: * typec_altmode_enter - Enter Mode\ndrivers/usb/typec/bus.c-118- * @adev: The alternate mode\n--\ndrivers/usb/typec/bus.c-125- */\ndrivers/usb/typec/bus.c:126:int typec_altmode_enter(struct typec_altmode *adev, u32 *vdo)\ndrivers/usb/typec/bus.c-127-{\n--\ndrivers/usb/typec/bus.c-148-}\ndrivers/usb/typec/bus.c:149:EXPORT_SYMBOL_GPL(typec_altmode_enter);\ndrivers/usb/typec/bus.c-150-\n"
}

gemini-3.8-flash

null

null

							input: 7203
							output: 32
							thoughts: 53
						

Here's my summary, as though I'm thinking through this process:

**Investigating Altmode Activation**

Okay, so I need to figure out the activation sequence for these alternate modes, specifically DisplayPort, over USB-C. The core of my question is: what's the actual function call that kicks off the altmode negotiation? Is it `dp_altmode_activate` or is it `typec_altmode_enter`? I know I've seen both mentioned, so I need to track down the direct call.

Since I am considering this issue for a driver, I will need to understand what methods exist to activate this mode. Now, I have heard whispers of sysfs potentially playing a role here. My immediate plan is to dive into the kernel source, focusing specifically on the `drivers/usb/typec` directory. I'll need to scrutinize the code in relation to `typec_altmode_activate` and any sysfs interactions within that context. I'll need to follow the execution path and identify how these calls or sysfs entries are initiated. That's where the real answer should be.

{
  "Expression": "dp_altmode_activate",
  "PathPrefix": "drivers/usb/typec"
}

{
  "Output": "drivers/usb/typec/altmodes/displayport.c=445=static int dp_cable_altmode_vdm(struct typec_altmode *alt, enum typec_plug_index sop,\n--\ndrivers/usb/typec/altmodes/displayport.c-503-\ndrivers/usb/typec/altmodes/displayport.c:504:static int dp_altmode_activate(struct typec_altmode *alt, int activate)\ndrivers/usb/typec/altmodes/displayport.c-505-{\n--\ndrivers/usb/typec/altmodes/displayport.c=525=static const struct typec_altmode_ops dp_altmode_ops = {\n--\ndrivers/usb/typec/altmodes/displayport.c-527-\t.vdm = dp_altmode_vdm,\ndrivers/usb/typec/altmodes/displayport.c:528:\t.activate = dp_altmode_activate,\ndrivers/usb/typec/altmodes/displayport.c-529-};\n"
}

gemini-3.8-flash

null

null

							input: 7800
							output: 29
							thoughts: 9
						

Okay, here's my summary, presented as a stream of thought:

**Diving into the Activation Logic**

Alright, time to dig into this `.activate` method. I need to understand what's happening under the hood. My expertise tells me this is likely a crucial piece of the puzzle, probably involved in bringing something to life, initiating a process, or transitioning a state. Let's start with a thorough investigation. I'm going to look at the surrounding code, see what objects or modules call this method, and trace the execution flow to grasp its purpose and impact. I’ll keep a sharp eye out for potential side effects, dependencies, and any error handling it might incorporate. Context is key, and I’ll use my deep understanding of the system's architecture to build a precise mental model of its role. This is more than just reading code; it’s about understanding the *why* behind the *what*. My goal is to extract the functional essence of `.activate`. Let's uncover the secrets within.

{
  "Expression": "-\u003eactivate\\(",
  "PathPrefix": "drivers/usb/typec"
}

{
  "Output": "drivers/usb/typec/class.c=368=static ssize_t active_store(struct device *dev, struct device_attribute *attr,\n--\ndrivers/usb/typec/class.c-397-\tif (adev-\u003eops \u0026\u0026 adev-\u003eops-\u003eactivate) {\ndrivers/usb/typec/class.c:398:\t\tret = adev-\u003eops-\u003eactivate(adev, enter);\ndrivers/usb/typec/class.c-399-\t\tif (ret)\n--\ndrivers/usb/typec/mode_selection.c=63=static int activate_altmode(struct device *dev, void *data)\n--\ndrivers/usb/typec/mode_selection.c-70-\t\t\tif (alt-\u003eops \u0026\u0026 alt-\u003eops-\u003eactivate)\ndrivers/usb/typec/mode_selection.c:71:\t\t\t\torder-\u003eresult = alt-\u003eops-\u003eactivate(alt, order-\u003eenter);\ndrivers/usb/typec/mode_selection.c-72-\t\t\telse\n"
}

gemini-3.8-flash

null

null

							input: 8303
							output: 27
							thoughts: 115
						

**Investigating the UCSI Device Instantiation**

Okay, so I'm diving into this `active_store` function within `drivers/usb/typec/class.c`. I see it's a sysfs attribute – that's a good starting point. Writing to this `active` attribute ultimately calls `adev->ops->activate`, which then leads to `typec_altmode_enter`. Now, my main question is, how exactly is this UCSI device instantiated in the first place?

The core issue is that I need to understand the underlying infrastructure that triggers this operation. Is it emulated or virtualized somehow within QEMU? Perhaps there's a virtual UCSI device, a mock implementation, or a platform device that I'm overlooking? Or, is this whole operation solely dependent on physical hardware? That's the real crux of this.

I think the best path forward is to thoroughly investigate all the UCSI drivers within the kernel. I need to get a clear picture of how these things are set up and initialized, to understand if I can reproduce or control this behavior in my testing environment.

{
  "Dir": "drivers/usb/typec/ucsi"
}

{
  "Files": [
    "cros_ec_ucsi.c",
    "debugfs.c",
    "displayport.c",
    "psy.c",
    "thunderbolt.c",
    "trace.c",
    "trace.h",
    "ucsi.c",
    "ucsi.h",
    "ucsi_acpi.c",
    "ucsi_ccg.c",
    "ucsi_glink.c",
    "ucsi_huawei_gaokun.c",
    "ucsi_stm32g0.c",
    "ucsi_yoga_c630.c"
  ],
  "Subdirs": null
}

gemini-3.8-flash

null

null

							input: 8829
							output: 34
							thoughts: 161
						

**My Initial Examination of UCSI Driver Files**

Okay, so I'm diving into the UCSI driver space, specifically looking at the files in `drivers/usb/typec/ucsi`. I see a comprehensive list: `cros_ec_ucsi.c`, `debugfs.c`, `displayport.c`, `psy.c`, `thunderbolt.c`, `trace.c`, `trace.h`, `ucsi.c`, `ucsi.h`, `ucsi_acpi.c`, `ucsi_ccg.c`, `ucsi_glink.c`, `ucsi_huawei_gaokun.c`, `ucsi_stm32g0.c`, and `ucsi_yoga_c630.c`. This is a pretty diverse set, reflecting the various implementations and features this subsystem likely supports.

Wait a minute, `displayport.c`... that file stands out. I need to understand how the DisplayPort functionality is being integrated here. How is it registered? Where does it fit into the UCSI picture? Let's zoom in on the `ucsi_displayport` calls within the `drivers/usb/typec/ucsi` directory. I need to trace the usage and integration of DisplayPort to understand its interaction with the UCSI framework.

{
  "Expression": "ucsi_displayport",
  "PathPrefix": "drivers/usb/typec/ucsi"
}

{
  "Output": "drivers/usb/typec/ucsi/displayport.c=18=struct ucsi_dp {\n--\ndrivers/usb/typec/ucsi/displayport.c-47-\ndrivers/usb/typec/ucsi/displayport.c:48:static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\ndrivers/usb/typec/ucsi/displayport.c-49-{\n--\ndrivers/usb/typec/ucsi/displayport.c-111-\ndrivers/usb/typec/ucsi/displayport.c:112:static int ucsi_displayport_exit(struct typec_altmode *alt)\ndrivers/usb/typec/ucsi/displayport.c-113-{\n--\ndrivers/usb/typec/ucsi/displayport.c-160- */\ndrivers/usb/typec/ucsi/displayport.c:161:static int ucsi_displayport_status_update(struct ucsi_dp *dp)\ndrivers/usb/typec/ucsi/displayport.c-162-{\n--\ndrivers/usb/typec/ucsi/displayport.c-188-\ndrivers/usb/typec/ucsi/displayport.c:189:static int ucsi_displayport_configure(struct ucsi_dp *dp)\ndrivers/usb/typec/ucsi/displayport.c-190-{\n--\ndrivers/usb/typec/ucsi/displayport.c-200-\ndrivers/usb/typec/ucsi/displayport.c:201:static int ucsi_displayport_vdm(struct typec_altmode *alt,\ndrivers/usb/typec/ucsi/displayport.c-202-\t\t\t\tu32 header, const u32 *data, int count)\n--\ndrivers/usb/typec/ucsi/displayport.c-238-\t\tcase DP_CMD_STATUS_UPDATE:\ndrivers/usb/typec/ucsi/displayport.c:239:\t\t\tif (ucsi_displayport_status_update(dp))\ndrivers/usb/typec/ucsi/displayport.c-240-\t\t\t\tdp-\u003eheader |= VDO_CMDT(CMDT_RSP_NAK);\n--\ndrivers/usb/typec/ucsi/displayport.c-249-\t\t\tdp-\u003edata.conf = *data;\ndrivers/usb/typec/ucsi/displayport.c:250:\t\t\tif (ucsi_displayport_configure(dp)) {\ndrivers/usb/typec/ucsi/displayport.c-251-\t\t\t\tdp-\u003eheader |= VDO_CMDT(CMDT_RSP_NAK);\n--\ndrivers/usb/typec/ucsi/displayport.c-275-\ndrivers/usb/typec/ucsi/displayport.c:276:static const struct typec_altmode_ops ucsi_displayport_ops = {\ndrivers/usb/typec/ucsi/displayport.c:277:\t.enter = ucsi_displayport_enter,\ndrivers/usb/typec/ucsi/displayport.c:278:\t.exit = ucsi_displayport_exit,\ndrivers/usb/typec/ucsi/displayport.c:279:\t.vdm = ucsi_displayport_vdm,\ndrivers/usb/typec/ucsi/displayport.c-280-};\ndrivers/usb/typec/ucsi/displayport.c-281-\ndrivers/usb/typec/ucsi/displayport.c:282:static void ucsi_displayport_work(struct work_struct *work)\ndrivers/usb/typec/ucsi/displayport.c-283-{\n--\ndrivers/usb/typec/ucsi/displayport.c-296-\ndrivers/usb/typec/ucsi/displayport.c:297:void ucsi_displayport_remove_partner(struct typec_altmode *alt)\ndrivers/usb/typec/ucsi/displayport.c-298-{\n--\ndrivers/usb/typec/ucsi/displayport.c=315=struct typec_altmode *ucsi_register_displayport(struct ucsi_connector *con,\n--\ndrivers/usb/typec/ucsi/displayport.c-340-\ndrivers/usb/typec/ucsi/displayport.c:341:\tINIT_WORK(\u0026dp-\u003ework, ucsi_displayport_work);\ndrivers/usb/typec/ucsi/displayport.c-342-\tdp-\u003eoverride = override;\n--\ndrivers/usb/typec/ucsi/displayport.c-346-\ndrivers/usb/typec/ucsi/displayport.c:347:\ttypec_altmode_set_ops(alt, \u0026ucsi_displayport_ops);\ndrivers/usb/typec/ucsi/displayport.c-348-\ttypec_altmode_set_drvdata(alt, dp);\n--\ndrivers/usb/typec/ucsi/ucsi.c=811=static void ucsi_unregister_altmodes(struct ucsi_connector *con, u8 recipient)\n--\ndrivers/usb/typec/ucsi/ucsi.c-837-\t\t\t     adev[i]-\u003evdo != USB_TYPEC_NVIDIA_VLINK_DBG_VDO))\ndrivers/usb/typec/ucsi/ucsi.c:838:\t\t\t\tucsi_displayport_remove_partner((void *)pdev);\ndrivers/usb/typec/ucsi/ucsi.c-839-\t\t\telse if (adev[i]-\u003esvid == USB_TYPEC_TBT_SID)\n--\ndrivers/usb/typec/ucsi/ucsi.h=607=ucsi_register_displayport(struct ucsi_connector *con,\n--\ndrivers/usb/typec/ucsi/ucsi.h-610-\ndrivers/usb/typec/ucsi/ucsi.h:611:void ucsi_displayport_remove_partner(struct typec_altmode *adev);\ndrivers/usb/typec/ucsi/ucsi.h-612-\n--\ndrivers/usb/typec/ucsi/ucsi.h=622=static inline void\ndrivers/usb/typec/ucsi/ucsi.h:623:ucsi_displayport_remove_partner(struct typec_altmode *adev) { }\ndrivers/usb/typec/ucsi/ucsi.h-624-#endif /* CONFIG_TYPEC_DP_ALTMODE */\n"
}

gemini-3.8-flash

null

null

							input: 10963
							output: 36
							thoughts: 47
						

Here's my thinking process:

**Analyzing the `ucsi_register_displayport` Function Call**

Okay, so I need to figure out the context of `ucsi_register_displayport`. The prompt tells me it's called within `ucsi.c`. My immediate thought is, "Right, let's trace this and see what's happening." I need to understand the function's purpose within the larger `ucsi` framework, and figuring out *where* it's called is the logical first step. I need to understand the call chain and what triggers the execution of that specific function. So, I need to zoom in on `ucsi.c` and isolate the call to `ucsi_register_displayport` within that file, and that should give me a good initial handle on its functionality.

{
  "Expression": "ucsi_register_displayport",
  "PathPrefix": "drivers/usb/typec/ucsi"
}

{
  "Output": "drivers/usb/typec/ucsi/displayport.c=297=void ucsi_displayport_remove_partner(struct typec_altmode *alt)\n--\ndrivers/usb/typec/ucsi/displayport.c-314-\ndrivers/usb/typec/ucsi/displayport.c:315:struct typec_altmode *ucsi_register_displayport(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/displayport.c-316-\t\t\t\t\t\tbool override, int offset,\n--\ndrivers/usb/typec/ucsi/ucsi.c=424=static int ucsi_register_altmode(struct ucsi_connector *con,\n--\ndrivers/usb/typec/ucsi/ucsi.c-450-\t\tcase USB_TYPEC_DP_SID:\ndrivers/usb/typec/ucsi/ucsi.c:451:\t\t\talt = ucsi_register_displayport(con, override, i, desc);\ndrivers/usb/typec/ucsi/ucsi.c-452-\t\t\tbreak;\n--\ndrivers/usb/typec/ucsi/ucsi.c-457-\t\t\telse\ndrivers/usb/typec/ucsi/ucsi.c:458:\t\t\t\talt = ucsi_register_displayport(con, override,\ndrivers/usb/typec/ucsi/ucsi.c-459-\t\t\t\t\t\t\t\ti, desc);\n--\ndrivers/usb/typec/ucsi/ucsi.h=606=struct typec_altmode *\ndrivers/usb/typec/ucsi/ucsi.h:607:ucsi_register_displayport(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.h-608-\t\t\t  bool override, int offset,\n--\ndrivers/usb/typec/ucsi/ucsi.h=614=static inline struct typec_altmode *\ndrivers/usb/typec/ucsi/ucsi.h:615:ucsi_register_displayport(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.h-616-\t\t\t  bool override, int offset,\n"
}

gemini-3.8-flash

null

null

							input: 11781
							output: 38
							thoughts: 42
						

**Delving into UCSI**

Okay, time to get a handle on this UCSI business. First, I need to remind myself precisely what it *is* and how it's brought into existence. Let's make sure I've got the instantiation process straight in my head. Then, the drivers...what exactly are the UCSI drivers responsible for? I'm thinking I'll find the best answers in the Kconfig file for `drivers/usb/typec/ucsi`. That's usually the go-to place for configuration options and dependencies within the kernel tree, and should illuminate the driver landscape pretty quickly. Right, let's dive into that Kconfig file.

{
  "File": "drivers/usb/typec/ucsi/Kconfig",
  "FirstLine": 1,
  "LineCount": 80
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0\n   2:\t\n   3:\tconfig TYPEC_UCSI\n   4:\t\ttristate \"USB Type-C Connector System Software Interface driver\"\n   5:\t\tdepends on !CPU_BIG_ENDIAN\n   6:\t\tdepends on USB_ROLE_SWITCH || !USB_ROLE_SWITCH\n   7:\t\tselect USB_COMMON if DEBUG_FS\n   8:\t\thelp\n   9:\t\t  USB Type-C Connector System Software Interface (UCSI) is a\n  10:\t\t  specification for an interface that allows the operating system to\n  11:\t\t  control the USB Type-C ports. On UCSI system the USB Type-C ports\n  12:\t\t  function autonomously by default, but in order to get the status of\n  13:\t\t  the ports and support basic operations like role swapping, the driver\n  14:\t\t  is required. UCSI is available on most of the new Intel based systems\n  15:\t\t  that are equipped with Embedded Controller and USB Type-C ports.\n  16:\t\n  17:\t\t  UCSI specification does not define the interface method, so depending\n  18:\t\t  on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this\n  19:\t\t  driver only provides the core part, and separate drivers are needed\n  20:\t\t  for every supported interface method.\n  21:\t\n  22:\t\t  The UCSI specification can be downloaded from:\n  23:\t\t  https://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html\n  24:\t\n  25:\t\t  To compile the driver as a module, choose M here: the module will be\n  26:\t\t  called typec_ucsi.\n  27:\t\n  28:\tif TYPEC_UCSI\n  29:\t\n  30:\tconfig UCSI_CCG\n  31:\t\ttristate \"UCSI Interface Driver for Cypress CCGx\"\n  32:\t\tdepends on I2C\n  33:\t\thelp\n  34:\t\t  This driver enables UCSI support on platforms that expose a\n  35:\t\t  Cypress CCGx Type-C controller over I2C interface.\n  36:\t\n  37:\t\t  To compile the driver as a module, choose M here: the module will be\n  38:\t\t  called ucsi_ccg.\n  39:\t\n  40:\tconfig UCSI_ACPI\n  41:\t\ttristate \"UCSI ACPI Interface Driver\"\n  42:\t\tdepends on ACPI\n  43:\t\thelp\n  44:\t\t  This driver enables UCSI support on platforms that expose UCSI\n  45:\t\t  interface as ACPI device. On new Intel Atom based platforms starting\n  46:\t\t  from Broxton SoCs and Core platforms stating from Skylake, UCSI is an\n  47:\t\t  ACPI enumerated device.\n  48:\t\n  49:\t\t  To compile the driver as a module, choose M here: the module will be\n  50:\t\t  called ucsi_acpi\n  51:\t\n  52:\tconfig UCSI_STM32G0\n  53:\t\ttristate \"UCSI Interface Driver for STM32G0\"\n  54:\t\tdepends on I2C\n  55:\t\thelp\n  56:\t\t  This driver enables UCSI support on platforms that expose a STM32G0\n  57:\t\t  Type-C controller over I2C interface.\n  58:\t\n  59:\t\t  To compile the driver as a module, choose M here: the module will be\n  60:\t\t  called ucsi_stm32g0.\n  61:\t\n  62:\tconfig UCSI_PMIC_GLINK\n  63:\t\ttristate \"UCSI Qualcomm PMIC GLINK Interface Driver\"\n  64:\t\tdepends on QCOM_PMIC_GLINK\n  65:\t\thelp\n  66:\t\t  This driver enables UCSI support on platforms that expose UCSI\n  67:\t\t  interface as PMIC GLINK device.\n  68:\t\n  69:\t\t  To compile the driver as a module, choose M here: the module will be\n  70:\t\t  called ucsi_glink.\n  71:\t\n  72:\tconfig CROS_EC_UCSI\n  73:\t\ttristate \"UCSI Driver for ChromeOS EC\"\n  74:\t\tdepends on MFD_CROS_EC_DEV\n  75:\t\tdepends on CROS_USBPD_NOTIFY\n  76:\t\tdefault MFD_CROS_EC_DEV\n  77:\t\thelp\n  78:\t\t  This driver enables UCSI support for a ChromeOS EC. The EC is\n  79:\t\t  expected to implement a PPM.\n  80:\t\n"
}

gemini-3.8-flash

null

null

							input: 13208
							output: 39
							thoughts: 10
						

Okay, here's my attempt at summarizing the thought process, tailored for an expert audience, and written in the first person:

**Diving into the Kconfig Depths**

Right, let's get down to brass tacks and really *dig* into this Kconfig situation. No more surface skimming, I need to get a comprehensive view. What's the complete picture here? I need to see *everything* Kconfig has to offer, from the simple statements to the most intricate dependencies. I'm thinking I want to go beyond a quick scan; this is more like a methodical review. I'm mentally breaking down all the sections, the intricate relationships between them, and how each component fits into the bigger picture. Time to get familiar with all the ins and outs.

{
  "File": "drivers/usb/typec/ucsi/Kconfig",
  "FirstLine": 81,
  "LineCount": 50
}

{
  "Contents": "  81:\t\t  To compile the driver as a module, choose M here: the module\n  82:\t\t  will be called cros_ec_ucsi.\n  83:\t\n  84:\tconfig UCSI_LENOVO_YOGA_C630\n  85:\t\ttristate \"UCSI Interface Driver for Lenovo Yoga C630\"\n  86:\t\tdepends on EC_LENOVO_YOGA_C630\n  87:\t\tdepends on DRM || !DRM\n  88:\t\tselect DRM_AUX_HPD_BRIDGE if DRM_BRIDGE \u0026\u0026 OF\n  89:\t\thelp\n  90:\t\t  This driver enables UCSI support on the Lenovo Yoga C630 laptop.\n  91:\t\n  92:\t\t  To compile the driver as a module, choose M here: the module will be\n  93:\t\t  called ucsi_yoga_c630.\n  94:\t\n  95:\tconfig UCSI_HUAWEI_GAOKUN\n  96:\t\ttristate \"UCSI Interface Driver for Huawei Matebook E Go\"\n  97:\t\tdepends on EC_HUAWEI_GAOKUN\n  98:\t\tdepends on DRM || !DRM\n  99:\t\tselect DRM_AUX_HPD_BRIDGE if DRM_BRIDGE \u0026\u0026 OF\n 100:\t\thelp\n 101:\t\t  This driver enables UCSI support on the Huawei Matebook E Go tablet,\n 102:\t\t  which is a sc8280xp-based 2-in-1 tablet.\n 103:\t\n 104:\t\t  To compile the driver as a module, choose M here: the module will be\n 105:\t\t  called ucsi_huawei_gaokun.\n 106:\t\n 107:\tendif\n"
}

gemini-3.8-flash

null

null

							input: 13870
							output: 37
							thoughts: 17
						

Here's a summary of my immediate thought process, as if I were considering the scenario:

**Examining the USB Type-C UCSI Makefile**

Okay, so I need to understand what's going on within the USB Type-C UCSI driver's build process. The logical first step, naturally, is to examine the `Makefile` located in `drivers/usb/typec/ucsi`. I need to see how the UCSI driver components are compiled, linked, and installed within the kernel build. I'll be looking for things like: the source files included, any specific compiler flags being used, dependencies on other modules or libraries (especially those related to USB or Type-C), and how the driver is potentially configured via Kconfig. I'm hoping to get a quick overview of its structure, pinpoint any areas where I can immediately influence the outcome of the build process, and identify any potential compile-time issues. Understanding the Makefile is absolutely critical before I can make any meaningful contributions or debugging efforts related to this area.

{
  "File": "drivers/usb/typec/ucsi/Makefile",
  "FirstLine": 1,
  "LineCount": 30
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0\n   2:\tCFLAGS_trace.o\t\t\t\t:= -I$(src)\n   3:\t\n   4:\tobj-$(CONFIG_TYPEC_UCSI)\t\t+= typec_ucsi.o\n   5:\t\n   6:\ttypec_ucsi-y\t\t\t\t:= ucsi.o\n   7:\t\n   8:\ttypec_ucsi-$(CONFIG_DEBUG_FS)\t\t+= debugfs.o\n   9:\t\n  10:\ttypec_ucsi-$(CONFIG_TRACING)\t\t+= trace.o\n  11:\t\n  12:\tifneq ($(CONFIG_POWER_SUPPLY),)\n  13:\t\ttypec_ucsi-y\t\t\t+= psy.o\n  14:\tendif\n  15:\t\n  16:\tifneq ($(CONFIG_TYPEC_DP_ALTMODE),)\n  17:\t\ttypec_ucsi-y\t\t\t+= displayport.o\n  18:\tendif\n  19:\t\n  20:\tifneq ($(CONFIG_TYPEC_TBT_ALTMODE),)\n  21:\t\ttypec_ucsi-y\t\t\t+= thunderbolt.o\n  22:\tendif\n  23:\t\n  24:\tobj-$(CONFIG_UCSI_ACPI)\t\t\t+= ucsi_acpi.o\n  25:\tobj-$(CONFIG_UCSI_CCG)\t\t\t+= ucsi_ccg.o\n  26:\tobj-$(CONFIG_UCSI_STM32G0)\t\t+= ucsi_stm32g0.o\n  27:\tobj-$(CONFIG_UCSI_PMIC_GLINK)\t\t+= ucsi_glink.o\n  28:\tobj-$(CONFIG_CROS_EC_UCSI)\t\t+= cros_ec_ucsi.o\n  29:\tobj-$(CONFIG_UCSI_LENOVO_YOGA_C630)\t+= ucsi_yoga_c630.o\n  30:\tobj-$(CONFIG_UCSI_HUAWEI_GAOKUN)\t+= ucsi_huawei_gaokun.o\n"
}

gemini-3.8-flash

null

null

							input: 14678
							output: 31
							thoughts: 42
						

Okay, let's dive into this. Here's how I'd approach this task, thinking through it step-by-step:

**Unpacking UCSI Instantiation**

Right, so the question is, *how* exactly does a UCSI instance come into being? I need to understand the lifecycle. First, I'll need to figure out which drivers are even capable of creating or making use of the UCSI interface. That means checking for any code which calls the core functions. What are the key points for this? I will target the functions `ucsi_register` or `ucsi_create` specifically. Any code that touches those is interesting.

Now, an important question arises: is physical hardware a hard requirement? Can a UCSI object exist in a software-defined environment, without directly being tied to a physical controller? This could have major implications for testing, virtualization, and how we handle errors. I need to know if the design allows for virtual instantiation. I will target the functions `ucsi_register` or `ucsi_create` specifically to identify whether or not this is the case.

Basically, I need a comprehensive overview of every place that *creates* or *registers* a UCSI object. It is a critical component for how a user interacts with the system, and that means I need to know who does it. I need to fully understand who is responsible, and how. That will give me the information I need to understand it at the highest level.

{
  "Expression": "ucsi_create|ucsi_register",
  "PathPrefix": "drivers/"
}

{
  "Output": "drivers/usb/typec/ucsi/cros_ec_ucsi.c=260=static int cros_ucsi_probe(struct platform_device *pdev)\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-288-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:289:\tudata-\u003eucsi = ucsi_create(dev, \u0026cros_ucsi_ops);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-290-\tif (IS_ERR(udata-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-302-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:303:\tret = ucsi_register(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-304-\tif (ret) {\n--\ndrivers/usb/typec/ucsi/displayport.c=297=void ucsi_displayport_remove_partner(struct typec_altmode *alt)\n--\ndrivers/usb/typec/ucsi/displayport.c-314-\ndrivers/usb/typec/ucsi/displayport.c:315:struct typec_altmode *ucsi_register_displayport(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/displayport.c-316-\t\t\t\t\t\tbool override, int offset,\n--\ndrivers/usb/typec/ucsi/psy.c=280=static int ucsi_psy_get_prop(struct power_supply *psy,\n--\ndrivers/usb/typec/ucsi/psy.c-311-\ndrivers/usb/typec/ucsi/psy.c:312:int ucsi_register_port_psy(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/psy.c-313-{\n--\ndrivers/usb/typec/ucsi/thunderbolt.c=170=static const struct typec_altmode_ops ucsi_thunderbolt_ops = {\n--\ndrivers/usb/typec/ucsi/thunderbolt.c-175-\ndrivers/usb/typec/ucsi/thunderbolt.c:176:struct typec_altmode *ucsi_register_thunderbolt(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/thunderbolt.c-177-\t\t\t\t\t\tbool override, int offset,\n--\ndrivers/usb/typec/ucsi/trace.h=74=DEFINE_EVENT(ucsi_log_connector_status, ucsi_connector_change,\n--\ndrivers/usb/typec/ucsi/trace.h-78-\ndrivers/usb/typec/ucsi/trace.h:79:DEFINE_EVENT(ucsi_log_connector_status, ucsi_register_port,\ndrivers/usb/typec/ucsi/trace.h-80-\tTP_PROTO(int port, struct ucsi_connector *con),\n--\ndrivers/usb/typec/ucsi/trace.h=84=DECLARE_EVENT_CLASS(ucsi_log_register_altmode,\n--\ndrivers/usb/typec/ucsi/trace.h-103-\ndrivers/usb/typec/ucsi/trace.h:104:DEFINE_EVENT(ucsi_log_register_altmode, ucsi_register_altmode,\ndrivers/usb/typec/ucsi/trace.h-105-\tTP_PROTO(u8 recipient, struct typec_altmode *alt),\n--\ndrivers/usb/typec/ucsi/ucsi.c=413=static int ucsi_get_num_altmode(struct typec_altmode **alt)\n--\ndrivers/usb/typec/ucsi/ucsi.c-423-\ndrivers/usb/typec/ucsi/ucsi.c:424:static int ucsi_register_altmode(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.c-425-\t\t\t\t struct typec_altmode_desc *desc,\n--\ndrivers/usb/typec/ucsi/ucsi.c-450-\t\tcase USB_TYPEC_DP_SID:\ndrivers/usb/typec/ucsi/ucsi.c:451:\t\t\talt = ucsi_register_displayport(con, override, i, desc);\ndrivers/usb/typec/ucsi/ucsi.c-452-\t\t\tbreak;\n--\ndrivers/usb/typec/ucsi/ucsi.c-457-\t\t\telse\ndrivers/usb/typec/ucsi/ucsi.c:458:\t\t\t\talt = ucsi_register_displayport(con, override,\ndrivers/usb/typec/ucsi/ucsi.c-459-\t\t\t\t\t\t\t\ti, desc);\n--\ndrivers/usb/typec/ucsi/ucsi.c-461-\t\tcase USB_TYPEC_TBT_SID:\ndrivers/usb/typec/ucsi/ucsi.c:462:\t\t\talt = ucsi_register_thunderbolt(con, override, i, desc);\ndrivers/usb/typec/ucsi/ucsi.c-463-\t\t\tbreak;\n--\ndrivers/usb/typec/ucsi/ucsi.c-521-\ndrivers/usb/typec/ucsi/ucsi.c:522:\ttrace_ucsi_register_altmode(recipient, alt);\ndrivers/usb/typec/ucsi/ucsi.c-523-\n--\ndrivers/usb/typec/ucsi/ucsi.c=656=static int\ndrivers/usb/typec/ucsi/ucsi.c:657:ucsi_register_altmodes_nvidia(struct ucsi_connector *con, u8 recipient)\ndrivers/usb/typec/ucsi/ucsi.c-658-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-728-\ndrivers/usb/typec/ucsi/ucsi.c:729:\t\tret = ucsi_register_altmode(con, \u0026desc, recipient);\ndrivers/usb/typec/ucsi/ucsi.c-730-\t\tif (ret)\n--\ndrivers/usb/typec/ucsi/ucsi.c-736-\ndrivers/usb/typec/ucsi/ucsi.c:737:static int ucsi_register_altmodes(struct ucsi_connector *con, u8 recipient)\ndrivers/usb/typec/ucsi/ucsi.c-738-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-755-\tif (con-\u003eucsi-\u003eops-\u003eupdate_altmodes)\ndrivers/usb/typec/ucsi/ucsi.c:756:\t\treturn ucsi_register_altmodes_nvidia(con, recipient);\ndrivers/usb/typec/ucsi/ucsi.c-757-\n--\ndrivers/usb/typec/ucsi/ucsi.c-801-\ndrivers/usb/typec/ucsi/ucsi.c:802:\t\t\tret = ucsi_register_altmode(con, \u0026desc, recipient);\ndrivers/usb/typec/ucsi/ucsi.c-803-\t\t\tif (ret)\n--\ndrivers/usb/typec/ucsi/ucsi.c=1013=static int ucsi_check_altmodes(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1016-\ndrivers/usb/typec/ucsi/ucsi.c:1017:\tret = ucsi_register_altmodes(con, UCSI_RECIPIENT_SOP);\ndrivers/usb/typec/ucsi/ucsi.c-1018-\tif (ret \u0026\u0026 ret != -ETIMEDOUT)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1037-\ndrivers/usb/typec/ucsi/ucsi.c:1038:static void ucsi_register_device_pdos(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/ucsi.c-1039-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-1059-\ndrivers/usb/typec/ucsi/ucsi.c:1060:static int ucsi_register_partner_pdos(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/ucsi.c-1061-{\n--\ndrivers/usb/typec/ucsi/ucsi.c=1087=static void ucsi_unregister_partner_pdos(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1096-\ndrivers/usb/typec/ucsi/ucsi.c:1097:static int ucsi_register_plug(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/ucsi.c-1098-{\n--\ndrivers/usb/typec/ucsi/ucsi.c=1114=static void ucsi_unregister_plug(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1123-\ndrivers/usb/typec/ucsi/ucsi.c:1124:static int ucsi_register_cable(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/ucsi.c-1125-{\n--\ndrivers/usb/typec/ucsi/ucsi.c=1228=static void ucsi_pwr_opmode_change(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1235-\t\tucsi_partner_task(con, ucsi_check_altmodes, 30, HZ);\ndrivers/usb/typec/ucsi/ucsi.c:1236:\t\tucsi_partner_task(con, ucsi_register_partner_pdos, 1, HZ);\ndrivers/usb/typec/ucsi/ucsi.c-1237-\t\tucsi_partner_task(con, ucsi_check_connector_capability, 1, HZ);\n--\ndrivers/usb/typec/ucsi/ucsi.c-1256-\ndrivers/usb/typec/ucsi/ucsi.c:1257:static int ucsi_register_partner(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/ucsi.c-1258-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-1279-\tif (pwr_opmode == UCSI_CONSTAT_PWR_OPMODE_PD)\ndrivers/usb/typec/ucsi/ucsi.c:1280:\t\tucsi_register_device_pdos(con);\ndrivers/usb/typec/ucsi/ucsi.c-1281-\n--\ndrivers/usb/typec/ucsi/ucsi.c=1382=static int ucsi_check_connection(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1395-\t\t\treturn 0;\ndrivers/usb/typec/ucsi/ucsi.c:1396:\t\tucsi_register_partner(con);\ndrivers/usb/typec/ucsi/ucsi.c-1397-\t\tucsi_pwr_opmode_change(con);\n--\ndrivers/usb/typec/ucsi/ucsi.c=1408=static int ucsi_check_cable(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1414-\ndrivers/usb/typec/ucsi/ucsi.c:1415:\tret = ucsi_register_cable(con);\ndrivers/usb/typec/ucsi/ucsi.c-1416-\tif (ret \u003c 0)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1425-\tif (con-\u003eucsi-\u003ecap.features \u0026 UCSI_CAP_ALT_MODE_DETAILS) {\ndrivers/usb/typec/ucsi/ucsi.c:1426:\t\tret = ucsi_register_plug(con);\ndrivers/usb/typec/ucsi/ucsi.c-1427-\t\tif (ret \u003c 0)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1429-\ndrivers/usb/typec/ucsi/ucsi.c:1430:\t\tret = ucsi_register_altmodes(con, UCSI_RECIPIENT_SOP_P);\ndrivers/usb/typec/ucsi/ucsi.c-1431-\t\tif (ret \u003c 0)\n--\ndrivers/usb/typec/ucsi/ucsi.c=1445=static void ucsi_handle_connector_change(struct work_struct *work)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1500-\t\tif (UCSI_CONSTAT(con, CONNECTED)) {\ndrivers/usb/typec/ucsi/ucsi.c:1501:\t\t\tucsi_register_partner(con);\ndrivers/usb/typec/ucsi/ucsi.c-1502-\t\t\tucsi_partner_task(con, ucsi_check_connection, 1, HZ);\n--\ndrivers/usb/typec/ucsi/ucsi.c-1508-\t\t\tif (UCSI_CONSTAT(con, PWR_OPMODE) == UCSI_CONSTAT_PWR_OPMODE_PD) {\ndrivers/usb/typec/ucsi/ucsi.c:1509:\t\t\t\tucsi_partner_task(con, ucsi_register_partner_pdos, 1, HZ);\ndrivers/usb/typec/ucsi/ucsi.c-1510-\t\t\t\tucsi_partner_task(con, ucsi_check_connector_capability, 1, HZ);\n--\ndrivers/usb/typec/ucsi/ucsi.c=1800=static struct fwnode_handle *ucsi_find_fwnode(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1810-\ndrivers/usb/typec/ucsi/ucsi.c:1811:static int ucsi_register_port(struct ucsi *ucsi, struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/ucsi.c-1812-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-1892-\ndrivers/usb/typec/ucsi/ucsi.c:1893:\tret = ucsi_register_port_psy(con);\ndrivers/usb/typec/ucsi/ucsi.c-1894-\tif (ret)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1904-\tif (!(ucsi-\u003equirks \u0026 UCSI_DELAY_DEVICE_PDOS))\ndrivers/usb/typec/ucsi/ucsi.c:1905:\t\tucsi_register_device_pdos(con);\ndrivers/usb/typec/ucsi/ucsi.c-1906-\ndrivers/usb/typec/ucsi/ucsi.c-1907-\t/* Alternate modes */\ndrivers/usb/typec/ucsi/ucsi.c:1908:\tret = ucsi_register_altmodes(con, UCSI_RECIPIENT_CON);\ndrivers/usb/typec/ucsi/ucsi.c-1909-\tif (ret) {\n--\ndrivers/usb/typec/ucsi/ucsi.c-1943-\t\ttypec_set_pwr_role(con-\u003eport, UCSI_CONSTAT(con, PWR_DIR));\ndrivers/usb/typec/ucsi/ucsi.c:1944:\t\tucsi_register_partner(con);\ndrivers/usb/typec/ucsi/ucsi.c-1945-\t\tucsi_pwr_opmode_change(con);\n--\ndrivers/usb/typec/ucsi/ucsi.c-1965-\tif (con-\u003epartner \u0026\u0026 UCSI_CONSTAT(con, PWR_OPMODE) == UCSI_CONSTAT_PWR_OPMODE_PD) {\ndrivers/usb/typec/ucsi/ucsi.c:1966:\t\tucsi_register_device_pdos(con);\ndrivers/usb/typec/ucsi/ucsi.c-1967-\t\tucsi_get_src_pdos(con);\n--\ndrivers/usb/typec/ucsi/ucsi.c-1971-\ndrivers/usb/typec/ucsi/ucsi.c:1972:\ttrace_ucsi_register_port(con-\u003enum, con);\ndrivers/usb/typec/ucsi/ucsi.c-1973-\n--\ndrivers/usb/typec/ucsi/ucsi.c=2067=static int ucsi_init(struct ucsi *ucsi)\n--\ndrivers/usb/typec/ucsi/ucsi.c-2119-\t\tconnector[i].num = i + 1;\ndrivers/usb/typec/ucsi/ucsi.c:2120:\t\tret = ucsi_register_port(ucsi, \u0026connector[i]);\ndrivers/usb/typec/ucsi/ucsi.c-2121-\t\tif (ret)\n--\ndrivers/usb/typec/ucsi/ucsi.c=2305=void ucsi_con_mutex_unlock(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-2310-/**\ndrivers/usb/typec/ucsi/ucsi.c:2311: * ucsi_create - Allocate UCSI instance\ndrivers/usb/typec/ucsi/ucsi.c-2312- * @dev: Device interface to the PPM (Platform Policy Manager)\n--\ndrivers/usb/typec/ucsi/ucsi.c-2314- */\ndrivers/usb/typec/ucsi/ucsi.c:2315:struct ucsi *ucsi_create(struct device *dev, const struct ucsi_operations *ops)\ndrivers/usb/typec/ucsi/ucsi.c-2316-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-2336-}\ndrivers/usb/typec/ucsi/ucsi.c:2337:EXPORT_SYMBOL_GPL(ucsi_create);\ndrivers/usb/typec/ucsi/ucsi.c-2338-\n--\ndrivers/usb/typec/ucsi/ucsi.c=2348=EXPORT_SYMBOL_GPL(ucsi_destroy);\n--\ndrivers/usb/typec/ucsi/ucsi.c-2350-/**\ndrivers/usb/typec/ucsi/ucsi.c:2351: * ucsi_register - Register UCSI interface\ndrivers/usb/typec/ucsi/ucsi.c-2352- * @ucsi: UCSI instance\ndrivers/usb/typec/ucsi/ucsi.c-2353- */\ndrivers/usb/typec/ucsi/ucsi.c:2354:int ucsi_register(struct ucsi *ucsi)\ndrivers/usb/typec/ucsi/ucsi.c-2355-{\n--\ndrivers/usb/typec/ucsi/ucsi.c-2378-}\ndrivers/usb/typec/ucsi/ucsi.c:2379:EXPORT_SYMBOL_GPL(ucsi_register);\ndrivers/usb/typec/ucsi/ucsi.c-2380-\n--\ndrivers/usb/typec/ucsi/ucsi.c-2384- *\ndrivers/usb/typec/ucsi/ucsi.c:2385: * Unregister UCSI interface that was created with ucsi_register().\ndrivers/usb/typec/ucsi/ucsi.c-2386- */\n--\ndrivers/usb/typec/ucsi/ucsi.h=81=struct ucsi_operations {\n--\ndrivers/usb/typec/ucsi/ucsi.h-98-\ndrivers/usb/typec/ucsi/ucsi.h:99:struct ucsi *ucsi_create(struct device *dev, const struct ucsi_operations *ops);\ndrivers/usb/typec/ucsi/ucsi.h-100-void ucsi_destroy(struct ucsi *ucsi);\ndrivers/usb/typec/ucsi/ucsi.h:101:int ucsi_register(struct ucsi *ucsi);\ndrivers/usb/typec/ucsi/ucsi.h-102-void ucsi_unregister(struct ucsi *ucsi);\n--\ndrivers/usb/typec/ucsi/ucsi.h=591=int ucsi_sync_control_common(struct ucsi *ucsi, u64 command, u32 *cci,\n--\ndrivers/usb/typec/ucsi/ucsi.h-595-#if IS_ENABLED(CONFIG_POWER_SUPPLY)\ndrivers/usb/typec/ucsi/ucsi.h:596:int ucsi_register_port_psy(struct ucsi_connector *con);\ndrivers/usb/typec/ucsi/ucsi.h-597-void ucsi_unregister_port_psy(struct ucsi_connector *con);\ndrivers/usb/typec/ucsi/ucsi.h=598=void ucsi_port_psy_changed(struct ucsi_connector *con);\ndrivers/usb/typec/ucsi/ucsi.h-599-#else\ndrivers/usb/typec/ucsi/ucsi.h:600:static inline int ucsi_register_port_psy(struct ucsi_connector *con) { return 0; }\ndrivers/usb/typec/ucsi/ucsi.h-601-static inline void ucsi_unregister_port_psy(struct ucsi_connector *con) { }\n--\ndrivers/usb/typec/ucsi/ucsi.h=606=struct typec_altmode *\ndrivers/usb/typec/ucsi/ucsi.h:607:ucsi_register_displayport(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.h-608-\t\t\t  bool override, int offset,\n--\ndrivers/usb/typec/ucsi/ucsi.h=614=static inline struct typec_altmode *\ndrivers/usb/typec/ucsi/ucsi.h:615:ucsi_register_displayport(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.h-616-\t\t\t  bool override, int offset,\n--\ndrivers/usb/typec/ucsi/ucsi.h=627=struct typec_altmode *\ndrivers/usb/typec/ucsi/ucsi.h:628:ucsi_register_thunderbolt(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.h-629-\t\t\t  bool override, int offset,\n--\ndrivers/usb/typec/ucsi/ucsi.h=634=static inline struct typec_altmode *\ndrivers/usb/typec/ucsi/ucsi.h:635:ucsi_register_thunderbolt(struct ucsi_connector *con,\ndrivers/usb/typec/ucsi/ucsi.h-636-\t\t\t  bool override, int offset,\n--\ndrivers/usb/typec/ucsi/ucsi_acpi.c=189=static int ucsi_acpi_probe(struct platform_device *pdev)\n--\ndrivers/usb/typec/ucsi/ucsi_acpi.c-225-\ndrivers/usb/typec/ucsi/ucsi_acpi.c:226:\tua-\u003eucsi = ucsi_create(\u0026pdev-\u003edev, ops);\ndrivers/usb/typec/ucsi/ucsi_acpi.c-227-\tif (IS_ERR(ua-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/ucsi_acpi.c-240-\ndrivers/usb/typec/ucsi/ucsi_acpi.c:241:\tret = ucsi_register(ua-\u003eucsi);\ndrivers/usb/typec/ucsi/ucsi_acpi.c-242-\tif (ret) {\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=1343=static int ccg_restart(struct ucsi_ccg *uc)\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1359-\ndrivers/usb/typec/ucsi/ucsi_ccg.c:1360:\tstatus = ucsi_register(uc-\u003eucsi);\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1361-\tif (status) {\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=1433=static int ucsi_ccg_probe(struct i2c_client *client)\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1479-\ndrivers/usb/typec/ucsi/ucsi_ccg.c:1480:\tuc-\u003eucsi = ucsi_create(dev, \u0026ucsi_ccg_ops);\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1481-\tif (IS_ERR(uc-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1491-\ndrivers/usb/typec/ucsi/ucsi_ccg.c:1492:\tstatus = ucsi_register(uc-\u003eucsi);\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1493-\tif (status)\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c=63=struct pmic_glink_ucsi {\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c-77-\tspinlock_t state_lock;\ndrivers/usb/typec/ucsi/ucsi_glink.c:78:\tbool ucsi_registered;\ndrivers/usb/typec/ucsi/ucsi_glink.c-79-\tbool pd_running;\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c=241=static void pmic_glink_ucsi_read_ack(struct pmic_glink_ucsi *ucsi, const void *data, int len)\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c-253-\t\t}\ndrivers/usb/typec/ucsi/ucsi_glink.c:254:\t} else if (!ucsi-\u003eucsi_registered) {\ndrivers/usb/typec/ucsi/ucsi_glink.c-255-\t\t/*\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c=298=static void pmic_glink_ucsi_notify(struct work_struct *work)\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c-312-\ndrivers/usb/typec/ucsi/ucsi_glink.c:313:static void pmic_glink_ucsi_register(struct work_struct *work)\ndrivers/usb/typec/ucsi/ucsi_glink.c-314-{\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c-322-\ndrivers/usb/typec/ucsi/ucsi_glink.c:323:\tif (!ucsi-\u003eucsi_registered \u0026\u0026 pd_running) {\ndrivers/usb/typec/ucsi/ucsi_glink.c:324:\t\tucsi_register(ucsi-\u003eucsi);\ndrivers/usb/typec/ucsi/ucsi_glink.c:325:\t\tucsi-\u003eucsi_registered = true;\ndrivers/usb/typec/ucsi/ucsi_glink.c:326:\t} else if (ucsi-\u003eucsi_registered \u0026\u0026 !pd_running) {\ndrivers/usb/typec/ucsi/ucsi_glink.c-327-\t\tucsi_unregister(ucsi-\u003eucsi);\ndrivers/usb/typec/ucsi/ucsi_glink.c:328:\t\tucsi-\u003eucsi_registered = false;\ndrivers/usb/typec/ucsi/ucsi_glink.c-329-\t}\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c=389=static int pmic_glink_ucsi_probe(struct auxiliary_device *adev,\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c-404-\tINIT_WORK(\u0026ucsi-\u003enotify_work, pmic_glink_ucsi_notify);\ndrivers/usb/typec/ucsi/ucsi_glink.c:405:\tINIT_WORK(\u0026ucsi-\u003eregister_work, pmic_glink_ucsi_register);\ndrivers/usb/typec/ucsi/ucsi_glink.c-406-\tinit_completion(\u0026ucsi-\u003eread_ack);\n--\ndrivers/usb/typec/ucsi/ucsi_glink.c-410-\ndrivers/usb/typec/ucsi/ucsi_glink.c:411:\tucsi-\u003eucsi = ucsi_create(dev, \u0026pmic_glink_ucsi_ops);\ndrivers/usb/typec/ucsi/ucsi_glink.c-412-\tif (IS_ERR(ucsi-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c=405=static int gaokun_ucsi_ports_init(struct gaokun_ucsi *uec)\n--\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-469-\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c:470:static void gaokun_ucsi_register_worker(struct work_struct *work)\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-471-{\n--\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-484-\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c:485:\tret = ucsi_register(ucsi);\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-486-\tif (ret) {\n--\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c=495=static int gaokun_ucsi_probe(struct auxiliary_device *adev,\n--\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-511-\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c:512:\tINIT_DELAYED_WORK(\u0026uec-\u003ework, gaokun_ucsi_register_worker);\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-513-\n--\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-517-\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c:518:\tuec-\u003eucsi = ucsi_create(dev, \u0026gaokun_ucsi_ops);\ndrivers/usb/typec/ucsi/ucsi_huawei_gaokun.c-519-\tif (IS_ERR(uec-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c=434=static int ucsi_stm32g0_register(struct ucsi *ucsi)\n--\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-447-\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c:448:\tret = ucsi_register(ucsi);\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-449-\tif (ret) {\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c:450:\t\tdev_err_probe(g0-\u003edev, ret, \"ucsi_register failed\\n\");\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-451-\t\tfree_irq(client-\u003eirq, g0);\n--\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c=615=static int ucsi_stm32g0_probe(struct i2c_client *client)\n--\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-628-\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c:629:\tg0-\u003eucsi = ucsi_create(dev, \u0026ucsi_stm32g0_ops);\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-630-\tif (IS_ERR(g0-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c=217=static int yoga_c630_ucsi_probe(struct auxiliary_device *adev,\n--\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c-248-\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c:249:\tuec-\u003eucsi = ucsi_create(\u0026adev-\u003edev, \u0026yoga_c630_ucsi_ops);\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c-250-\tif (IS_ERR(uec-\u003eucsi))\n--\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c-262-\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c:263:\tret = ucsi_register(uec-\u003eucsi);\ndrivers/usb/typec/ucsi/ucsi_yoga_c630.c-264-\tif (ret)\n"
}

gemini-3.8-flash

null

null

							input: 23896
							output: 46
							thoughts: 410
						

**My Analysis of UCSI Driver Implementations**

Okay, let's break down these UCSI driver implementations. First, I see `cros_ec_ucsi.c`, which is clearly ChromeOS EC specific. That's straightforward; it needs the ChromeOS EC. Next, `ucsi_acpi.c` uses ACPI and looks for a device with the PNP/ACPI ID "PNP0CA0" or "USBC000". Hmm, can QEMU even *create* ACPI devices with "PNP0CA0"? Standard QEMU ACPI doesn't include that. And can I, using something like syzkaller, conjure up an ACPI device on the fly? Probably not, unless I'm using configfs or custom DSDT/SSDT table loading, which isn't the syzkaller MO.

Then, there's `ucsi_ccg.c`, an I2C client for Cypress CCGx, and `ucsi_stm32g0.c`, also an I2C client. My mind immediately jumps to I2C possibilities – could I use `i2c-dev` or a dummy I2C bus to instantiate these devices from userspace via sysfs? Can I?

Wait, what about that `new_device` file? Can I do something like `echo "ucsi_ccg 0x08" > /sys/bus/i2c/devices/i2c-0/new_device`? If CONFIG_I2C is enabled and there's an I2C bus available (i801 or a dummy one, for example), I've seen that file. But the million-dollar question is, will `ucsi_ccg`'s probe function actually *succeed* without the real hardware?

Right, the smart move is to look at the `ucsi_ccg_probe` function itself in `drivers/usb/typec/ucsi/ucsi_ccg.c` and dig into the requirements.

{
  "File": "drivers/usb/typec/ucsi/ucsi_ccg.c",
  "FirstLine": 1430,
  "LineCount": 70
}

{
  "Contents": "1430:\t\tNULL,\n1431:\t};\n1432:\t\n1433:\tstatic int ucsi_ccg_probe(struct i2c_client *client)\n1434:\t{\n1435:\t\tstruct device *dev = \u0026client-\u003edev;\n1436:\t\tstruct ucsi_ccg *uc;\n1437:\t\tconst char *fw_name;\n1438:\t\tint status;\n1439:\t\n1440:\t\tuc = devm_kzalloc(dev, sizeof(*uc), GFP_KERNEL);\n1441:\t\tif (!uc)\n1442:\t\t\treturn -ENOMEM;\n1443:\t\n1444:\t\tuc-\u003edev = dev;\n1445:\t\tuc-\u003eclient = client;\n1446:\t\tuc-\u003eirq = client-\u003eirq;\n1447:\t\tmutex_init(\u0026uc-\u003elock);\n1448:\t\tINIT_WORK(\u0026uc-\u003ework, ccg_update_firmware);\n1449:\t\tINIT_WORK(\u0026uc-\u003epm_work, ccg_pm_workaround_work);\n1450:\t\n1451:\t\t/* Only fail FW flashing when FW build information is not provided */\n1452:\t\tstatus = device_property_read_string(dev, \"firmware-name\", \u0026fw_name);\n1453:\t\tif (!status) {\n1454:\t\t\tif (!strcmp(fw_name, \"nvidia,jetson-agx-xavier\"))\n1455:\t\t\t\tuc-\u003efw_build = CCG_FW_BUILD_NVIDIA_TEGRA;\n1456:\t\t\telse if (!strcmp(fw_name, \"nvidia,gpu\"))\n1457:\t\t\t\tuc-\u003efw_build = CCG_FW_BUILD_NVIDIA;\n1458:\t\t\tif (!uc-\u003efw_build)\n1459:\t\t\t\tdev_err(uc-\u003edev, \"failed to get FW build information\\n\");\n1460:\t\t}\n1461:\t\n1462:\t\t/* reset ccg device and initialize ucsi */\n1463:\t\tstatus = ucsi_ccg_init(uc);\n1464:\t\tif (status \u003c 0) {\n1465:\t\t\tdev_err(uc-\u003edev, \"ucsi_ccg_init failed - %d\\n\", status);\n1466:\t\t\treturn status;\n1467:\t\t}\n1468:\t\n1469:\t\tstatus = get_fw_info(uc);\n1470:\t\tif (status \u003c 0) {\n1471:\t\t\tdev_err(uc-\u003edev, \"get_fw_info failed - %d\\n\", status);\n1472:\t\t\treturn status;\n1473:\t\t}\n1474:\t\n1475:\t\tuc-\u003eport_num = 1;\n1476:\t\n1477:\t\tif (uc-\u003einfo.mode \u0026 CCG_DEVINFO_PDPORTS_MASK)\n1478:\t\t\tuc-\u003eport_num++;\n1479:\t\n1480:\t\tuc-\u003eucsi = ucsi_create(dev, \u0026ucsi_ccg_ops);\n1481:\t\tif (IS_ERR(uc-\u003eucsi))\n1482:\t\t\treturn PTR_ERR(uc-\u003eucsi);\n1483:\t\n1484:\t\tucsi_set_drvdata(uc-\u003eucsi, uc);\n1485:\t\n1486:\t\tstatus = ccg_request_irq(uc);\n1487:\t\tif (status \u003c 0) {\n1488:\t\t\tdev_err(uc-\u003edev, \"request_threaded_irq failed - %d\\n\", status);\n1489:\t\t\tgoto out_ucsi_destroy;\n1490:\t\t}\n1491:\t\n1492:\t\tstatus = ucsi_register(uc-\u003eucsi);\n1493:\t\tif (status)\n1494:\t\t\tgoto out_free_irq;\n1495:\t\n1496:\t\ti2c_set_clientdata(client, uc);\n1497:\t\n1498:\t\tdevice_disable_async_suspend(uc-\u003edev);\n1499:\t\n"
}

gemini-3.8-flash

null

null

							input: 25884
							output: 48
							thoughts: 67
						

**My Initial Thoughts on UCSI Driver Initialization**

Okay, so `ucsi_ccg_init` is the function that's kicking things off here. Right, it's pretty clear that it's using I2C to communicate. It needs to read those registers, verify the firmware mode... the usual handshake stuff. The key point is that it *needs* an actual device responding with the CCG protocol on the other end of the I2C bus, otherwise, it's just going to throw an I/O error, as you'd expect. Makes sense. But what about `ucsi_stm32g0`? I need to look into that one specifically. Let's see what's happening there...

{
  "File": "drivers/usb/typec/ucsi/ucsi_stm32g0.c",
  "FirstLine": 615,
  "LineCount": 50
}

{
  "Contents": " 615:\tstatic int ucsi_stm32g0_probe(struct i2c_client *client)\n 616:\t{\n 617:\t\tstruct device *dev = \u0026client-\u003edev;\n 618:\t\tstruct ucsi_stm32g0 *g0;\n 619:\t\tint ret;\n 620:\t\n 621:\t\tg0 = devm_kzalloc(dev, sizeof(*g0), GFP_KERNEL);\n 622:\t\tif (!g0)\n 623:\t\t\treturn -ENOMEM;\n 624:\t\n 625:\t\tg0-\u003edev = dev;\n 626:\t\tg0-\u003eclient = client;\n 627:\t\ti2c_set_clientdata(client, g0);\n 628:\t\n 629:\t\tg0-\u003eucsi = ucsi_create(dev, \u0026ucsi_stm32g0_ops);\n 630:\t\tif (IS_ERR(g0-\u003eucsi))\n 631:\t\t\treturn PTR_ERR(g0-\u003eucsi);\n 632:\t\n 633:\t\tucsi_set_drvdata(g0-\u003eucsi, g0);\n 634:\t\n 635:\t\tret = ucsi_stm32g0_probe_bootloader(g0-\u003eucsi);\n 636:\t\tif (ret \u003c 0)\n 637:\t\t\tgoto destroy;\n 638:\t\n 639:\t\t/*\n 640:\t\t * Don't register in bootloader mode: wait for the firmware to be loaded and started before\n 641:\t\t * registering UCSI device.\n 642:\t\t */\n 643:\t\tif (!g0-\u003ein_bootloader) {\n 644:\t\t\tret = ucsi_stm32g0_register(g0-\u003eucsi);\n 645:\t\t\tif (ret \u003c 0)\n 646:\t\t\t\tgoto freei2c;\n 647:\t\t}\n 648:\t\n 649:\t\tif (g0-\u003efw_name) {\n 650:\t\t\t/*\n 651:\t\t\t * Asynchronously flash (e.g. bootloader mode) or update the running firmware,\n 652:\t\t\t * not to hang the boot process\n 653:\t\t\t */\n 654:\t\t\tret = request_firmware_nowait(THIS_MODULE, FW_ACTION_UEVENT, g0-\u003efw_name, g0-\u003edev,\n 655:\t\t\t\t\t\t      GFP_KERNEL, g0-\u003eucsi, ucsi_stm32g0_fw_cb);\n 656:\t\t\tif (ret \u003c 0) {\n 657:\t\t\t\tdev_err_probe(dev, ret, \"firmware request failed\\n\");\n 658:\t\t\t\tgoto unregister;\n 659:\t\t\t}\n 660:\t\t}\n 661:\t\n 662:\t\treturn 0;\n 663:\t\n 664:\tunregister:\n"
}

gemini-3.8-flash

null

null

							input: 26934
							output: 48
							thoughts: 77
						

Here's my summary, as if I were thinking it:

**Digging into the STM32G0 UCSI Driver**

Okay, let's get down to brass tacks here. I need to understand how this `ucsi_stm32g0` driver actually boots up or if it even *requires* a real hardware setup. My first port of call is the `ucsi_stm32g0_probe_bootloader` function and related code. I'm focusing specifically on lines 520 through 560 in `drivers/usb/typec/ucsi/ucsi_stm32g0.c`. I need to figure out the bootloader probing sequence. Let's see what's what. This is where the initial bring-up logic will be. Time to dig in and understand.

{
  "File": "drivers/usb/typec/ucsi/ucsi_stm32g0.c",
  "FirstLine": 520,
  "LineCount": 50
}

{
  "Contents": " 520:\t\t\tdev_err(g0-\u003edev, \"Erase failed %d\\n\", ret);\n 521:\t\t\tgoto fw_release;\n 522:\t\t}\n 523:\t\n 524:\t\tdata = fw-\u003edata;\n 525:\t\tend = fw-\u003edata + fw-\u003esize;\n 526:\t\twhile (data \u003c end) {\n 527:\t\t\tsize = min(end - data, STM32G0_I2C_BL_SZ);\n 528:\t\t\tret = ucsi_stm32g0_bl_write(g0-\u003eucsi, addr, data, size);\n 529:\t\t\tif (ret) {\n 530:\t\t\t\tdev_err(g0-\u003edev, \"Write failed %d\\n\", ret);\n 531:\t\t\t\tgoto fw_release;\n 532:\t\t\t}\n 533:\t\t\taddr += size;\n 534:\t\t\tdata += size;\n 535:\t\t}\n 536:\t\n 537:\t\tdev_dbg(g0-\u003edev, \"Configure to boot from main flash\\n\");\n 538:\t\n 539:\t\tret = ucsi_stm32g0_bl_read(g0-\u003eucsi, STM32G0_USER_OPTION_BYTES, \u0026ob, sizeof(ob));\n 540:\t\tif (ret) {\n 541:\t\t\tdev_err(g0-\u003edev, \"read user option bytes failed %d\\n\", ret);\n 542:\t\t\tgoto fw_release;\n 543:\t\t}\n 544:\t\n 545:\t\tdev_dbg(g0-\u003edev, \"STM32G0_USER_OPTION_BYTES 0x%08x\\n\", ob);\n 546:\t\n 547:\t\t/* Configure user option bytes to boot from main flash next time */\n 548:\t\tob |= STM32G0_USER_OB_BOOT_MAIN;\n 549:\t\n 550:\t\t/* Writing option bytes will also reset G0 for updates to be loaded */\n 551:\t\tret = ucsi_stm32g0_bl_write(g0-\u003eucsi, STM32G0_USER_OPTION_BYTES, \u0026ob, sizeof(ob));\n 552:\t\tif (ret) {\n 553:\t\t\tdev_err(g0-\u003edev, \"write user option bytes failed %d\\n\", ret);\n 554:\t\t\tgoto fw_release;\n 555:\t\t}\n 556:\t\n 557:\t\tdev_info(g0-\u003edev, \"Starting, option bytes:0x%08x\\n\", ob);\n 558:\t\n 559:\t\t/* STM32G0 FW boot delay */\n 560:\t\tmsleep(500);\n 561:\t\n 562:\t\t/* Register UCSI interface */\n 563:\t\tif (!ucsi_stm32g0_register(g0-\u003eucsi))\n 564:\t\t\tg0-\u003ein_bootloader = false;\n 565:\t\n 566:\tfw_release:\n 567:\t\trelease_firmware(fw);\n 568:\t}\n 569:\t\n"
}

gemini-3.8-flash

null

null

							input: 28074
							output: 48
							thoughts: 53
						

Here's my take on those lines of code, presented as if I were thinking it through:

**Analyzing `ucsi_stm32g0_probe_bootloader` in the UCSI STM32G0 Driver**

Okay, I need to get a handle on what's happening with the bootloader probing in the STM32G0 UCSI driver. Let's dive straight into `drivers/usb/typec/ucsi/ucsi_stm32g0.c`, specifically lines 470 through 520. That's where `ucsi_stm32g0_probe_bootloader` should be defined. I'm expecting this function to be critical for the initial setup. I bet it is tasked with detecting if we have a bootloader running on the USB-C controller, determine its version, and possibly initialize or configure things based on that information. It will probably check for some specific vendor commands or data structures that are only available after the bootloader has been loaded or if it is running at the moment the driver probe is executed. I should be looking for things like register reads to identify the device and perhaps write operations to get it to switch modes. And I'm assuming that proper initialization would be key to ensuring a smooth user experience.

{
  "File": "drivers/usb/typec/ucsi/ucsi_stm32g0.c",
  "FirstLine": 470,
  "LineCount": 50
}

{
  "Contents": " 470:\t\tconst u8 *data, *end;\n 471:\t\tconst struct ucsi_stm32g0_fw_info *fw_info;\n 472:\t\tu32 addr = STM32G0_MAIN_MEM_ADDR, ob, fw_version;\n 473:\t\tint ret, size;\n 474:\t\n 475:\t\tif (!context)\n 476:\t\t\treturn;\n 477:\t\n 478:\t\tg0 = ucsi_get_drvdata(context);\n 479:\t\n 480:\t\tif (!fw)\n 481:\t\t\tgoto fw_release;\n 482:\t\n 483:\t\tfw_info = (struct ucsi_stm32g0_fw_info *)(fw-\u003edata + fw-\u003esize - sizeof(*fw_info));\n 484:\t\n 485:\t\tif (!g0-\u003ein_bootloader) {\n 486:\t\t\t/* Read running firmware version */\n 487:\t\t\tret = ucsi_stm32g0_fw_cmd(g0-\u003eucsi, STM32G0_FW_GETVER);\n 488:\t\t\tif (ret) {\n 489:\t\t\t\tdev_err(g0-\u003edev, \"Get version cmd failed %d\\n\", ret);\n 490:\t\t\t\tgoto fw_release;\n 491:\t\t\t}\n 492:\t\t\tret = ucsi_stm32g0_fw_rcv(g0-\u003eucsi, \u0026fw_version,\n 493:\t\t\t\t\t\t  STM32G0_FW_GETVER_LEN);\n 494:\t\t\tif (ret) {\n 495:\t\t\t\tdev_err(g0-\u003edev, \"Get version failed %d\\n\", ret);\n 496:\t\t\t\tgoto fw_release;\n 497:\t\t\t}\n 498:\t\n 499:\t\t\t/* Sanity check on keyword and firmware version */\n 500:\t\t\tif (fw_info-\u003ekeyword != STM32G0_FW_KEYWORD || fw_info-\u003eversion == fw_version)\n 501:\t\t\t\tgoto fw_release;\n 502:\t\n 503:\t\t\tdev_info(g0-\u003edev, \"Flashing FW: %08x (%08x cur)\\n\", fw_info-\u003eversion, fw_version);\n 504:\t\n 505:\t\t\t/* Switch to bootloader mode */\n 506:\t\t\tucsi_stm32g0_unregister(g0-\u003eucsi);\n 507:\t\t\tret = ucsi_stm32g0_fw_cmd(g0-\u003eucsi, STM32G0_FW_RSTGOBL);\n 508:\t\t\tif (ret) {\n 509:\t\t\t\tdev_err(g0-\u003edev, \"bootloader cmd failed %d\\n\", ret);\n 510:\t\t\t\tgoto fw_release;\n 511:\t\t\t}\n 512:\t\t\tg0-\u003ein_bootloader = true;\n 513:\t\n 514:\t\t\t/* STM32G0 reboot delay */\n 515:\t\t\tmsleep(100);\n 516:\t\t}\n 517:\t\n 518:\t\tret = ucsi_stm32g0_bl_global_mass_erase(g0-\u003eucsi);\n 519:\t\tif (ret) {\n"
}

gemini-3.8-flash

null

null

							input: 29314
							output: 48
							thoughts: 56
						

Here's my summary, as if I were thinking these thoughts:

**Digging into the UCSI STM32G0 Bootloader Probe**

Okay, hold on a second... before I get too deep into this problem, I need to circle back. Wasn't there something about `ucsi_stm32g0_probe_bootloader` that I need to consider? I've been focusing on X, Y, and Z, but that function could be crucial here. Let me quickly double-check that probe routine, the bootloader probing specifically. I should take a look at the implementation within the `ucsi_stm32g0.c` file. Let me focus on lines 390 through 435. That section likely holds the key to how the system determines whether the bootloader is present, and might offer important clues as to where my issue resides, if it isn't an underlying hardware fault. Let's see what's what in those lines...

{
  "File": "drivers/usb/typec/ucsi/ucsi_stm32g0.c",
  "FirstLine": 390,
  "LineCount": 45
}

{
  "Contents": " 390:\t\n 391:\t\tbuf[0] = UCSI_CONTROL;\n 392:\t\tmemcpy(\u0026buf[1], \u0026command, sizeof(command));\n 393:\t\tmsg[0].len = sizeof(command) + 1;\n 394:\t\tmsg[0].buf = buf;\n 395:\t\n 396:\t\tret = i2c_transfer(client-\u003eadapter, msg, ARRAY_SIZE(msg));\n 397:\t\tkfree(buf);\n 398:\t\tif (ret != ARRAY_SIZE(msg)) {\n 399:\t\t\tdev_err(g0-\u003edev, \"i2c write %02x, %02x error: %d\\n\", client-\u003eaddr, UCSI_CONTROL, ret);\n 400:\t\n 401:\t\t\treturn ret \u003c 0 ? ret : -EIO;\n 402:\t\t}\n 403:\t\n 404:\t\treturn 0;\n 405:\t}\n 406:\t\n 407:\tstatic irqreturn_t ucsi_stm32g0_irq_handler(int irq, void *data)\n 408:\t{\n 409:\t\tstruct ucsi_stm32g0 *g0 = data;\n 410:\t\tu32 cci;\n 411:\t\tint ret;\n 412:\t\n 413:\t\tif (g0-\u003esuspended)\n 414:\t\t\tg0-\u003ewakeup_event = true;\n 415:\t\n 416:\t\tret = ucsi_stm32g0_read(g0-\u003eucsi, UCSI_CCI, \u0026cci, sizeof(cci));\n 417:\t\tif (ret)\n 418:\t\t\treturn IRQ_NONE;\n 419:\t\n 420:\t\tucsi_notify_common(g0-\u003eucsi, cci);\n 421:\t\n 422:\t\treturn IRQ_HANDLED;\n 423:\t}\n 424:\t\n 425:\tstatic const struct ucsi_operations ucsi_stm32g0_ops = {\n 426:\t\t.read_version = ucsi_stm32g0_read_version,\n 427:\t\t.read_cci = ucsi_stm32g0_read_cci,\n 428:\t\t.poll_cci = ucsi_stm32g0_read_cci,\n 429:\t\t.read_message_in = ucsi_stm32g0_read_message_in,\n 430:\t\t.sync_control = ucsi_sync_control_common,\n 431:\t\t.async_control = ucsi_stm32g0_async_control,\n 432:\t};\n 433:\t\n 434:\tstatic int ucsi_stm32g0_register(struct ucsi *ucsi)\n"
}

gemini-3.8-flash

null

null

							input: 30391
							output: 43
							thoughts: 69
						

Here's my summary, as though I'm thinking through this code:

**Diving into the UCSI Registration**

Okay, so I'm tracking down how this UCSI driver registers itself. First thing's first, I see `ucsi_stm32g0_register` is called, which makes sense, it's specific to the STM32G0 variant. That's a good starting point. Now, the key function here seems to be `ucsi_register(ucsi)`. I've seen that name before; it's the core registration function.

Let's dig into `ucsi_register` and understand exactly what's happening. I'll jump over to the `drivers/usb/typec/ucsi/ucsi.c` file and get my bearings. I need to understand the fundamental registration steps. I want to see how the driver hooks into the system, how it acquires resources, and how it sets up its interaction with the USB Type-C hardware and the rest of the stack. I expect this to be the core of the UCSI driver, setting up the foundation for all subsequent operations.

{
  "File": "drivers/usb/typec/ucsi/ucsi.c",
  "FirstLine": 2350,
  "LineCount": 40
}

{
  "Contents": "2350:\t/**\n2351:\t * ucsi_register - Register UCSI interface\n2352:\t * @ucsi: UCSI instance\n2353:\t */\n2354:\tint ucsi_register(struct ucsi *ucsi)\n2355:\t{\n2356:\t\tint ret;\n2357:\t\n2358:\t\tret = ucsi-\u003eops-\u003eread_version(ucsi, \u0026ucsi-\u003eversion);\n2359:\t\tif (ret)\n2360:\t\t\treturn ret;\n2361:\t\n2362:\t\tif (!ucsi-\u003eversion)\n2363:\t\t\treturn -ENODEV;\n2364:\t\n2365:\t\t/*\n2366:\t\t * Version format is JJ.M.N (JJ = Major version, M = Minor version,\n2367:\t\t * N = sub-minor version).\n2368:\t\t */\n2369:\t\tdev_dbg(ucsi-\u003edev, \"Registered UCSI interface with version %x.%x.%x\",\n2370:\t\t\tUCSI_BCD_GET_MAJOR(ucsi-\u003eversion),\n2371:\t\t\tUCSI_BCD_GET_MINOR(ucsi-\u003eversion),\n2372:\t\t\tUCSI_BCD_GET_SUBMINOR(ucsi-\u003eversion));\n2373:\t\n2374:\t\tqueue_delayed_work(system_dfl_long_wq, \u0026ucsi-\u003ework, 0);\n2375:\t\n2376:\t\tucsi_debugfs_register(ucsi);\n2377:\t\treturn 0;\n2378:\t}\n2379:\tEXPORT_SYMBOL_GPL(ucsi_register);\n2380:\t\n2381:\t/**\n2382:\t * ucsi_unregister - Unregister UCSI interface\n2383:\t * @ucsi: UCSI interface to be unregistered\n2384:\t *\n2385:\t * Unregister UCSI interface that was created with ucsi_register().\n2386:\t */\n2387:\tvoid ucsi_unregister(struct ucsi *ucsi)\n2388:\t{\n2389:\t\tu64 cmd = UCSI_SET_NOTIFICATION_ENABLE;\n"
}

gemini-3.8-flash

null

null

							input: 31342
							output: 26
							thoughts: 277
						

**My UCSI Driver Investigation**

Okay, so I'm thinking, "Which drivers are actually *responsible* for creating UCSI devices within the kernel?" I need to make sure I'm not missing anything crucial here, so let's dig into this. Are there any other drivers besides the ones I'm already aware of?

I know I looked for `ucsi_create` before, but let's just make sure I have all the bases covered. I've got:

*   `drivers/usb/typec/ucsi/cros_ec_ucsi.c` for ChromeOS EC.
*   `drivers/usb/typec/ucsi/ucsi_acpi.c` for ACPI devices.
*   `drivers/usb/typec/ucsi/ucsi_ccg.c` for Cypress CCGx I2C.
*   `drivers/usb/typec/ucsi/ucsi_glink.c` for Qualcomm PMIC GLINK.
*   `drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c` for Huawei EC auxiliary devices.
*   `drivers/usb/typec/ucsi/ucsi_stm32g0.c` for STM32G0 I2C.
*   `drivers/usb/typec/ucsi/ucsi_yoga_c630.c` for Lenovo Yoga C630 EC auxiliary devices.

But hold on! What about any virtual UCSI drivers? Could there be some test code or a mocking setup that I'm overlooking? Also, are there any USB gadget drivers that create UCSI instances? Better search the kernel more broadly. I'm going to search for `ucsi` directly now, rather than just `ucsi_create`, to see what else turns up. It's time to refine my search and cover all possible UCSI instantiations.

{
  "Expression": "ucsi",
  "PathPrefix": "drivers/usb/"
}

{
  "Output": "\nFull output is too long, showing 500 out of 4213 lines.\nUse more precise expression if possible.\n\ndrivers/usb/typec/Kconfig=49=source \"drivers/usb/typec/tcpm/Kconfig\"\ndrivers/usb/typec/Kconfig-50-\ndrivers/usb/typec/Kconfig:51:source \"drivers/usb/typec/ucsi/Kconfig\"\ndrivers/usb/typec/Kconfig-52-\n--\ndrivers/usb/typec/Makefile=6=obj-$(CONFIG_TYPEC_TCPM)\t+= tcpm/\ndrivers/usb/typec/Makefile:7:obj-$(CONFIG_TYPEC_UCSI)\t+= ucsi/\ndrivers/usb/typec/Makefile-8-obj-$(CONFIG_TYPEC_TPS6598X)\t+= tipd/\n--\ndrivers/usb/typec/ucsi/Kconfig=3=config TYPEC_UCSI\n--\ndrivers/usb/typec/ucsi/Kconfig-22-\t  The UCSI specification can be downloaded from:\ndrivers/usb/typec/ucsi/Kconfig:23:\t  https://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html\ndrivers/usb/typec/ucsi/Kconfig-24-\ndrivers/usb/typec/ucsi/Kconfig-25-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:26:\t  called typec_ucsi.\ndrivers/usb/typec/ucsi/Kconfig-27-\n--\ndrivers/usb/typec/ucsi/Kconfig=30=config UCSI_CCG\n--\ndrivers/usb/typec/ucsi/Kconfig-37-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:38:\t  called ucsi_ccg.\ndrivers/usb/typec/ucsi/Kconfig-39-\ndrivers/usb/typec/ucsi/Kconfig=40=config UCSI_ACPI\n--\ndrivers/usb/typec/ucsi/Kconfig-49-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:50:\t  called ucsi_acpi\ndrivers/usb/typec/ucsi/Kconfig-51-\ndrivers/usb/typec/ucsi/Kconfig=52=config UCSI_STM32G0\n--\ndrivers/usb/typec/ucsi/Kconfig-59-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:60:\t  called ucsi_stm32g0.\ndrivers/usb/typec/ucsi/Kconfig-61-\ndrivers/usb/typec/ucsi/Kconfig=62=config UCSI_PMIC_GLINK\n--\ndrivers/usb/typec/ucsi/Kconfig-69-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:70:\t  called ucsi_glink.\ndrivers/usb/typec/ucsi/Kconfig-71-\ndrivers/usb/typec/ucsi/Kconfig=72=config CROS_EC_UCSI\n--\ndrivers/usb/typec/ucsi/Kconfig-81-\t  To compile the driver as a module, choose M here: the module\ndrivers/usb/typec/ucsi/Kconfig:82:\t  will be called cros_ec_ucsi.\ndrivers/usb/typec/ucsi/Kconfig-83-\ndrivers/usb/typec/ucsi/Kconfig=84=config UCSI_LENOVO_YOGA_C630\n--\ndrivers/usb/typec/ucsi/Kconfig-92-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:93:\t  called ucsi_yoga_c630.\ndrivers/usb/typec/ucsi/Kconfig-94-\ndrivers/usb/typec/ucsi/Kconfig=95=config UCSI_HUAWEI_GAOKUN\n--\ndrivers/usb/typec/ucsi/Kconfig-104-\t  To compile the driver as a module, choose M here: the module will be\ndrivers/usb/typec/ucsi/Kconfig:105:\t  called ucsi_huawei_gaokun.\ndrivers/usb/typec/ucsi/Kconfig-106-\n--\ndrivers/usb/typec/ucsi/Makefile=2=CFLAGS_trace.o\t\t\t\t:= -I$(src)\ndrivers/usb/typec/ucsi/Makefile-3-\ndrivers/usb/typec/ucsi/Makefile:4:obj-$(CONFIG_TYPEC_UCSI)\t\t+= typec_ucsi.o\ndrivers/usb/typec/ucsi/Makefile-5-\ndrivers/usb/typec/ucsi/Makefile:6:typec_ucsi-y\t\t\t\t:= ucsi.o\ndrivers/usb/typec/ucsi/Makefile-7-\ndrivers/usb/typec/ucsi/Makefile:8:typec_ucsi-$(CONFIG_DEBUG_FS)\t\t+= debugfs.o\ndrivers/usb/typec/ucsi/Makefile-9-\ndrivers/usb/typec/ucsi/Makefile:10:typec_ucsi-$(CONFIG_TRACING)\t\t+= trace.o\ndrivers/usb/typec/ucsi/Makefile-11-\ndrivers/usb/typec/ucsi/Makefile=12=ifneq ($(CONFIG_POWER_SUPPLY),)\ndrivers/usb/typec/ucsi/Makefile:13:\ttypec_ucsi-y\t\t\t+= psy.o\ndrivers/usb/typec/ucsi/Makefile-14-endif\n--\ndrivers/usb/typec/ucsi/Makefile=16=ifneq ($(CONFIG_TYPEC_DP_ALTMODE),)\ndrivers/usb/typec/ucsi/Makefile:17:\ttypec_ucsi-y\t\t\t+= displayport.o\ndrivers/usb/typec/ucsi/Makefile-18-endif\n--\ndrivers/usb/typec/ucsi/Makefile=20=ifneq ($(CONFIG_TYPEC_TBT_ALTMODE),)\ndrivers/usb/typec/ucsi/Makefile:21:\ttypec_ucsi-y\t\t\t+= thunderbolt.o\ndrivers/usb/typec/ucsi/Makefile-22-endif\ndrivers/usb/typec/ucsi/Makefile-23-\ndrivers/usb/typec/ucsi/Makefile:24:obj-$(CONFIG_UCSI_ACPI)\t\t\t+= ucsi_acpi.o\ndrivers/usb/typec/ucsi/Makefile:25:obj-$(CONFIG_UCSI_CCG)\t\t\t+= ucsi_ccg.o\ndrivers/usb/typec/ucsi/Makefile:26:obj-$(CONFIG_UCSI_STM32G0)\t\t+= ucsi_stm32g0.o\ndrivers/usb/typec/ucsi/Makefile:27:obj-$(CONFIG_UCSI_PMIC_GLINK)\t\t+= ucsi_glink.o\ndrivers/usb/typec/ucsi/Makefile:28:obj-$(CONFIG_CROS_EC_UCSI)\t\t+= cros_ec_ucsi.o\ndrivers/usb/typec/ucsi/Makefile:29:obj-$(CONFIG_UCSI_LENOVO_YOGA_C630)\t+= ucsi_yoga_c630.o\ndrivers/usb/typec/ucsi/Makefile:30:obj-$(CONFIG_UCSI_HUAWEI_GAOKUN)\t+= ucsi_huawei_gaokun.o\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-21-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:22:#include \"ucsi.h\"\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-23-\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-29-/*\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:30: * Maximum time in milliseconds the cros_ec_ucsi driver\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-31- * will wait for a response to a command or and ack.\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c=41=static const unsigned int mode_selection_timeout = 4000;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-42-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:43:struct cros_ucsi_data {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-44-\tstruct device *dev;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:45:\tstruct ucsi *ucsi;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-46-\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-56-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:57:static int cros_ucsi_read(struct ucsi *ucsi, unsigned int offset, void *val,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-58-\t\t\t  size_t val_len)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-59-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:60:\tstruct cros_ucsi_data *udata = ucsi_get_drvdata(ucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:61:\tstruct ec_params_ucsi_ppm_get req = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-62-\t\t.offset = offset,\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-80-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:81:static int cros_ucsi_read_version(struct ucsi *ucsi, u16 *version)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-82-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:83:\treturn cros_ucsi_read(ucsi, UCSI_VERSION, version, sizeof(*version));\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-84-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-85-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:86:static int cros_ucsi_read_cci(struct ucsi *ucsi, u32 *cci)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-87-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:88:\treturn cros_ucsi_read(ucsi, UCSI_CCI, cci, sizeof(*cci));\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-89-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-90-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:91:static int cros_ucsi_read_message_in(struct ucsi *ucsi, void *val,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-92-\t\t\t\t     size_t val_len)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-93-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:94:\treturn cros_ucsi_read(ucsi, UCSI_MESSAGE_IN, val, val_len);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-95-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-96-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:97:static int cros_ucsi_async_control(struct ucsi *ucsi, u64 cmd)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-98-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:99:\tstruct cros_ucsi_data *udata = ucsi_get_drvdata(ucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:100:\tu8 ec_buf[sizeof(struct ec_params_ucsi_ppm_set) + sizeof(cmd)];\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:101:\tstruct ec_params_ucsi_ppm_set *req = (struct ec_params_ucsi_ppm_set *) ec_buf;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-102-\tint ret;\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-114-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:115:static int cros_ucsi_sync_control(struct ucsi *ucsi, u64 cmd, u32 *cci,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-116-\t\t\t\t  void *data, size_t size, void *msg_out,\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-118-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:119:\tstruct cros_ucsi_data *udata = ucsi_get_drvdata(ucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-120-\tint ret;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-121-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:122:\tret = ucsi_sync_control_common(ucsi, cmd, cci, data, size, msg_out,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-123-\t\t\t\t       msg_out_size);\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-145-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:146:static void cros_ucsi_add_partner_altmodes(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-147-{\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-153-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:154:static void cros_ucsi_remove_partner_altmodes(struct ucsi_connector *con)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-155-{\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-159-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:160:static const struct ucsi_operations cros_ucsi_ops = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:161:\t.read_version = cros_ucsi_read_version,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:162:\t.read_cci = cros_ucsi_read_cci,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:163:\t.poll_cci = cros_ucsi_read_cci,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:164:\t.read_message_in = cros_ucsi_read_message_in,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:165:\t.async_control = cros_ucsi_async_control,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:166:\t.sync_control = cros_ucsi_sync_control,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:167:\t.add_partner_altmodes = cros_ucsi_add_partner_altmodes,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:168:\t.remove_partner_altmodes = cros_ucsi_remove_partner_altmodes,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-169-};\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-170-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:171:static void cros_ucsi_work(struct work_struct *work)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-172-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:173:\tstruct cros_ucsi_data *udata = container_of(work, struct cros_ucsi_data, work);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-174-\tu32 cci;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-175-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:176:\tif (cros_ucsi_read_cci(udata-\u003eucsi, \u0026cci))\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-177-\t\treturn;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-178-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:179:\tucsi_notify_common(udata-\u003eucsi, cci);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-180-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-181-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:182:static void cros_ucsi_write_timeout(struct work_struct *work)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-183-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:184:\tstruct cros_ucsi_data *udata =\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:185:\t\tcontainer_of(work, struct cros_ucsi_data, write_tmo.work);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-186-\tu32 cci;\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-188-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:189:\tif (cros_ucsi_read(udata-\u003eucsi, UCSI_CCI, \u0026cci, sizeof(cci))) {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-190-\t\tdev_err(udata-\u003edev,\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-213-\t\tcmd = UCSI_ACK_CC_CI | UCSI_ACK_COMMAND_COMPLETE;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:214:\t\tcros_ucsi_async_control(udata-\u003eucsi, cmd);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-215-\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-226-\t */\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:227:\tucsi_resume(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-228-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-229-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:230:static int cros_ucsi_event(struct notifier_block *nb,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-231-\t\t\t   unsigned long host_event, void *_notify)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-232-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:233:\tstruct cros_ucsi_data *udata = container_of(nb, struct cros_ucsi_data, nb);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-234-\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-239-\t\tdev_dbg(udata-\u003edev, \"Late PD init received\\n\");\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:240:\t\tucsi_resume(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-241-\t}\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-251-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:252:static void cros_ucsi_destroy(struct cros_ucsi_data *udata)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-253-{\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-256-\tcancel_work_sync(\u0026udata-\u003ework);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:257:\tucsi_destroy(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-258-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-259-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:260:static int cros_ucsi_probe(struct platform_device *pdev)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-261-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-262-\tstruct device *dev = \u0026pdev-\u003edev;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:263:\tstruct cros_ucsi_data *udata;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-264-\tint ret;\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-269-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:270:\t/* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:271:\t * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:272:\t * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-273-\t */\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-284-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:285:\tINIT_WORK(\u0026udata-\u003ework, cros_ucsi_work);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:286:\tINIT_DELAYED_WORK(\u0026udata-\u003ewrite_tmo, cros_ucsi_write_timeout);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-287-\tinit_completion(\u0026udata-\u003ecomplete);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-288-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:289:\tudata-\u003eucsi = ucsi_create(dev, \u0026cros_ucsi_ops);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:290:\tif (IS_ERR(udata-\u003eucsi))\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:291:\t\treturn dev_err_probe(dev, PTR_ERR(udata-\u003eucsi), \"failed to allocate UCSI instance\\n\");\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-292-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:293:\tucsi_set_drvdata(udata-\u003eucsi, udata);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-294-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:295:\tudata-\u003enb.notifier_call = cros_ucsi_event;\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-296-\tret = cros_usbpd_register_notify(\u0026udata-\u003enb);\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-298-\t\tdev_err_probe(dev, ret, \"failed to register notifier\\n\");\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:299:\t\tucsi_destroy(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-300-\t\treturn ret;\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-302-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:303:\tret = ucsi_register(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-304-\tif (ret) {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-305-\t\tdev_err_probe(dev, ret, \"failed to register UCSI\\n\");\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:306:\t\tcros_ucsi_destroy(udata);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-307-\t\treturn ret;\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-312-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:313:static void cros_ucsi_remove(struct platform_device *dev)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-314-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:315:\tstruct cros_ucsi_data *udata = platform_get_drvdata(dev);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-316-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:317:\tucsi_unregister(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:318:\tcros_ucsi_destroy(udata);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-319-}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-320-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:321:static int __maybe_unused cros_ucsi_suspend(struct device *dev)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-322-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:323:\tstruct cros_ucsi_data *udata = dev_get_drvdata(dev);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-324-\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-330-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:331:static void __maybe_unused cros_ucsi_complete(struct device *dev)\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-332-{\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:333:\tstruct cros_ucsi_data *udata = dev_get_drvdata(dev);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-334-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:335:\tucsi_resume(udata-\u003eucsi);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-336-}\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-342- * the .complete() callback of the cros_ec_lpc driver is executed.\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:343: * For this reason we delay ucsi_resume() until the .complete() stage\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-344- * otherwise UCSI SET_NOTIFICATION_ENABLE command will fail and we won't\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-346- */\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:347:static const struct dev_pm_ops cros_ucsi_pm_ops = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-348-#ifdef CONFIG_PM_SLEEP\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:349:\t.suspend = cros_ucsi_suspend,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:350:\t.complete = cros_ucsi_complete,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-351-#endif\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-353-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:354:static const struct platform_device_id cros_ucsi_id[] = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-355-\t{ KBUILD_MODNAME, 0 },\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-357-};\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:358:MODULE_DEVICE_TABLE(platform, cros_ucsi_id);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-359-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:360:static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-361-\t{ \"GOOG0021\", 0 },\n--\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-363-};\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:364:MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-365-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:366:static const struct of_device_id cros_ucsi_of_match[] = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:367:\t{ .compatible = \"google,cros-ec-ucsi\", },\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-368-\t{}\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-369-};\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:370:MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-371-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:372:static struct platform_driver cros_ucsi_driver = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-373-\t.driver = {\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-374-\t\t.name = KBUILD_MODNAME,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:375:\t\t.pm = \u0026cros_ucsi_pm_ops,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:376:\t\t.acpi_match_table = cros_ec_ucsi_acpi_device_ids,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:377:\t\t.of_match_table = cros_ucsi_of_match,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-378-\t},\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:379:\t.id_table = cros_ucsi_id,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:380:\t.probe = cros_ucsi_probe,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:381:\t.remove = cros_ucsi_remove,\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-382-};\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-383-\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c:384:module_platform_driver(cros_ucsi_driver);\ndrivers/usb/typec/ucsi/cros_ec_ucsi.c-385-\n--\ndrivers/usb/typec/ucsi/debugfs.c-18-\ndrivers/usb/typec/ucsi/debugfs.c:19:#include \"ucsi.h\"\ndrivers/usb/typec/ucsi/debugfs.c-20-\ndrivers/usb/typec/ucsi/debugfs.c:21:static struct dentry *ucsi_debugfs_root;\ndrivers/usb/typec/ucsi/debugfs.c-22-\ndrivers/usb/typec/ucsi/debugfs.c:23:static int ucsi_cmd(void *data, u64 val)\ndrivers/usb/typec/ucsi/debugfs.c-24-{\ndrivers/usb/typec/ucsi/debugfs.c:25:\tstruct ucsi *ucsi = data;\ndrivers/usb/typec/ucsi/debugfs.c-26-\tint ret;\ndrivers/usb/typec/ucsi/debugfs.c-27-\ndrivers/usb/typec/ucsi/debugfs.c:28:\tmemset(\u0026ucsi-\u003edebugfs-\u003eresponse, 0, sizeof(ucsi-\u003edebugfs-\u003eresponse));\ndrivers/usb/typec/ucsi/debugfs.c:29:\tucsi-\u003edebugfs-\u003estatus = 0;\ndrivers/usb/typec/ucsi/debugfs.c-30-\n--\ndrivers/usb/typec/ucsi/debugfs.c-40-\tcase UCSI_READ_POWER_LEVEL:\ndrivers/usb/typec/ucsi/debugfs.c:41:\t\tret = ucsi_send_command(ucsi, val, NULL, 0);\ndrivers/usb/typec/ucsi/debugfs.c-42-\t\tbreak;\ndrivers/usb/typec/ucsi/debugfs.c-43-\tcase UCSI_SET_PDOS:\ndrivers/usb/typec/ucsi/debugfs.c:44:\t\tret = ucsi_write_message_out_command(ucsi, val, NULL, 0,\ndrivers/usb/typec/ucsi/debugfs.c:45:\t\t\t\t\t\t     ucsi-\u003edebugfs-\u003emessage_out,\ndrivers/usb/typec/ucsi/debugfs.c-46-\t\t\t\t\t\t     UCSI_COMMAND_DATA_LEN(val));\n--\ndrivers/usb/typec/ucsi/debugfs.c-60-\tcase UCSI_GET_LPM_PPM_INFO:\ndrivers/usb/typec/ucsi/debugfs.c:61:\t\tret = ucsi_send_command(ucsi, val,\ndrivers/usb/typec/ucsi/debugfs.c:62:\t\t\t\t\t\u0026ucsi-\u003edebugfs-\u003eresponse,\ndrivers/usb/typec/ucsi/debugfs.c:63:\t\t\t\t\tsizeof(ucsi-\u003edebugfs-\u003eresponse));\ndrivers/usb/typec/ucsi/debugfs.c-64-\t\tbreak;\n--\ndrivers/usb/typec/ucsi/debugfs.c-69-\tif (ret \u003c 0) {\ndrivers/usb/typec/ucsi/debugfs.c:70:\t\tucsi-\u003edebugfs-\u003estatus = ret;\ndrivers/usb/typec/ucsi/debugfs.c-71-\t\treturn ret;\n--\ndrivers/usb/typec/ucsi/debugfs.c-75-}\ndrivers/usb/typec/ucsi/debugfs.c:76:DEFINE_DEBUGFS_ATTRIBUTE(ucsi_cmd_fops, NULL, ucsi_cmd, \"0x%llx\\n\");\ndrivers/usb/typec/ucsi/debugfs.c-77-\ndrivers/usb/typec/ucsi/debugfs.c:78:static int ucsi_resp_show(struct seq_file *s, void *not_used)\ndrivers/usb/typec/ucsi/debugfs.c-79-{\ndrivers/usb/typec/ucsi/debugfs.c:80:\tstruct ucsi *ucsi = s-\u003eprivate;\ndrivers/usb/typec/ucsi/debugfs.c-81-\ndrivers/usb/typec/ucsi/debugfs.c:82:\tif (ucsi-\u003edebugfs-\u003estatus)\ndrivers/usb/typec/ucsi/debugfs.c:83:\t\treturn ucsi-\u003edebugfs-\u003estatus;\ndrivers/usb/typec/ucsi/debugfs.c-84-\ndrivers/usb/typec/ucsi/debugfs.c:85:\tseq_printf(s, \"0x%016llx%016llx%016llx\\n\", ucsi-\u003edebugfs-\u003eresponse.ext,\ndrivers/usb/typec/ucsi/debugfs.c:86:\t\t   ucsi-\u003edebugfs-\u003eresponse.high, ucsi-\u003edebugfs-\u003eresponse.low);\ndrivers/usb/typec/ucsi/debugfs.c-87-\treturn 0;\ndrivers/usb/typec/ucsi/debugfs.c-88-}\ndrivers/usb/typec/ucsi/debugfs.c:89:DEFINE_SHOW_ATTRIBUTE(ucsi_resp);\ndrivers/usb/typec/ucsi/debugfs.c-90-\ndrivers/usb/typec/ucsi/debugfs.c:91:static int ucsi_peak_curr_show(struct seq_file *m, void *v)\ndrivers/usb/typec/ucsi/debugfs.c-92-{\ndrivers/usb/typec/ucsi/debugfs.c:93:\tstruct ucsi *ucsi = m-\u003eprivate;\ndrivers/usb/typec/ucsi/debugfs.c-94-\ndrivers/usb/typec/ucsi/debugfs.c:95:\tseq_printf(m, \"%u mA\\n\", ucsi-\u003econnector-\u003epeak_current);\ndrivers/usb/typec/ucsi/debugfs.c-96-\treturn 0;\ndrivers/usb/typec/ucsi/debugfs.c-97-}\ndrivers/usb/typec/ucsi/debugfs.c:98:DEFINE_SHOW_ATTRIBUTE(ucsi_peak_curr);\ndrivers/usb/typec/ucsi/debugfs.c-99-\ndrivers/usb/typec/ucsi/debugfs.c:100:static int ucsi_avg_curr_show(struct seq_file *m, void *v)\ndrivers/usb/typec/ucsi/debugfs.c-101-{\ndrivers/usb/typec/ucsi/debugfs.c:102:\tstruct ucsi *ucsi = m-\u003eprivate;\ndrivers/usb/typec/ucsi/debugfs.c-103-\ndrivers/usb/typec/ucsi/debugfs.c:104:\tseq_printf(m, \"%u mA\\n\", ucsi-\u003econnector-\u003eavg_current);\ndrivers/usb/typec/ucsi/debugfs.c-105-\treturn 0;\ndrivers/usb/typec/ucsi/debugfs.c-106-}\ndrivers/usb/typec/ucsi/debugfs.c:107:DEFINE_SHOW_ATTRIBUTE(ucsi_avg_curr);\ndrivers/usb/typec/ucsi/debugfs.c-108-\ndrivers/usb/typec/ucsi/debugfs.c:109:static int ucsi_vbus_volt_show(struct seq_file *m, void *v)\ndrivers/usb/typec/ucsi/debugfs.c-110-{\ndrivers/usb/typec/ucsi/debugfs.c:111:\tstruct ucsi *ucsi = m-\u003eprivate;\ndrivers/usb/typec/ucsi/debugfs.c-112-\ndrivers/usb/typec/ucsi/debugfs.c:113:\tseq_printf(m, \"%u mV\\n\", ucsi-\u003econnector-\u003evbus_voltage);\ndrivers/usb/typec/ucsi/debugfs.c-114-\treturn 0;\ndrivers/usb/typec/ucsi/debugfs.c-115-}\ndrivers/usb/typec/ucsi/debugfs.c:116:DEFINE_SHOW_ATTRIBUTE(ucsi_vbus_volt);\ndrivers/usb/typec/ucsi/debugfs.c-117-\ndrivers/usb/typec/ucsi/debugfs.c:118:static ssize_t ucsi_message_out_write(struct file *file,\ndrivers/usb/typec/ucsi/debugfs.c-119-\t\t\t\t      const char __user *data, size_t count, loff_t *ppos)\ndrivers/usb/typec/ucsi/debugfs.c-120-{\ndrivers/usb/typec/ucsi/debugfs.c:121:\tstruct ucsi *ucsi = file-\u003eprivate_data;\ndrivers/usb/typec/ucsi/debugfs.c-122-\tint ret;\n--\ndrivers/usb/typec/ucsi/debugfs.c-127-\ndrivers/usb/typec/ucsi/debugfs.c:128:\tret = hex2bin(ucsi-\u003edebugfs-\u003emessage_out, buf,\ndrivers/usb/typec/ucsi/debugfs.c:129:\t\t      min(count / 2, sizeof(ucsi-\u003edebugfs-\u003emessage_out)));\ndrivers/usb/typec/ucsi/debugfs.c-130-\tif (ret)\n--\ndrivers/usb/typec/ucsi/debugfs.c-135-\ndrivers/usb/typec/ucsi/debugfs.c:136:static const struct file_operations ucsi_message_out_fops = {\ndrivers/usb/typec/ucsi/debugfs.c-137-\t.open = simple_open,\ndrivers/usb/typec/ucsi/debugfs.c:138:\t.write = ucsi_message_out_write,\ndrivers/usb/typec/ucsi/debugfs.c-139-\t.llseek = generic_file_llseek,\n--\ndrivers/usb/typec/ucsi/debugfs.c-141-\ndrivers/usb/typec/ucsi/debugfs.c:142:void ucsi_debugfs_register(struct ucsi *ucsi)\ndrivers/usb/typec/ucsi/debugfs.c-143-{\ndrivers/usb/typec/ucsi/debugfs.c:144:\tucsi-\u003edebugfs = kzalloc_obj(*ucsi-\u003edebugfs);\ndrivers/usb/typec/ucsi/debugfs.c:145:\tif (!ucsi-\u003edebugfs)\ndrivers/usb/typec/ucsi/debugfs.c-146-\t\treturn;\ndrivers/usb/typec/ucsi/debugfs.c-147-\ndrivers/usb/typec/ucsi/debugfs.c:148:\tucsi-\u003edebugfs-\u003edentry = debugfs_create_dir(dev_name(ucsi-\u003edev), ucsi_debugfs_root);\ndrivers/usb/typec/ucsi/debugfs.c:149:\tdebugfs_create_file(\"command\", 0200, ucsi-\u003edebugfs-\u003edentry, ucsi, \u0026ucsi_cmd_fops);\ndrivers/usb/typec/ucsi/debugfs.c:150:\tdebugfs_create_file(\"response\", 0400, ucsi-\u003edebugfs-\u003edentry, ucsi, \u0026ucsi_resp_fops);\ndrivers/usb/typec/ucsi/debugfs.c:151:\tdebugfs_create_file(\"peak_current\", 0400, ucsi-\u003edebugfs-\u003edentry, ucsi, \u0026ucsi_peak_curr_fops);\ndrivers/usb/typec/ucsi/debugfs.c:152:\tdebugfs_create_file(\"avg_current\", 0400, ucsi-\u003edebugfs-\u003edentry, ucsi, \u0026ucsi_avg_curr_fops);\ndrivers/usb/typec/ucsi/debugfs.c:153:\tdebugfs_create_file(\"vbus_voltage\", 0400, ucsi-\u003edebugfs-\u003edentry, ucsi, \u0026ucsi_vbus_volt_fops);\ndrivers/usb/typec/ucsi/debugfs.c:154:\tdebugfs_create_file(\"message_out\", 0200, ucsi-\u003edebugfs-\u003edentry, ucsi,\ndrivers/usb/typec/ucsi/debugfs.c:155:\t\t\t    \u0026ucsi_message_out_fops);\ndrivers/usb/typec/ucsi/debugfs.c-156-}\ndrivers/usb/typec/ucsi/debugfs.c-157-\ndrivers/usb/typec/ucsi/debugfs.c:158:void ucsi_debugfs_unregister(struct ucsi *ucsi)\ndrivers/usb/typec/ucsi/debugfs.c-159-{\ndrivers/usb/typec/ucsi/debugfs.c:160:\tif (IS_ERR_OR_NULL(ucsi) || !ucsi-\u003edebugfs)\ndrivers/usb/typec/ucsi/debugfs.c-161-\t\treturn;\ndrivers/usb/typec/ucsi/debugfs.c-162-\ndrivers/usb/typec/ucsi/debugfs.c:163:\tdebugfs_remove_recursive(ucsi-\u003edebugfs-\u003edentry);\ndrivers/usb/typec/ucsi/debugfs.c:164:\tkfree(ucsi-\u003edebugfs);\ndrivers/usb/typec/ucsi/debugfs.c:165:\tucsi-\u003edebugfs = NULL;\ndrivers/usb/typec/ucsi/debugfs.c-166-}\ndrivers/usb/typec/ucsi/debugfs.c-167-\ndrivers/usb/typec/ucsi/debugfs.c:168:void ucsi_debugfs_init(void)\ndrivers/usb/typec/ucsi/debugfs.c-169-{\ndrivers/usb/typec/ucsi/debugfs.c:170:\tucsi_debugfs_root = debugfs_create_dir(\"ucsi\", usb_debug_root);\ndrivers/usb/typec/ucsi/debugfs.c-171-}\ndrivers/usb/typec/ucsi/debugfs.c-172-\ndrivers/usb/typec/ucsi/debugfs.c:173:void ucsi_debugfs_exit(void)\ndrivers/usb/typec/ucsi/debugfs.c-174-{\ndrivers/usb/typec/ucsi/debugfs.c:175:\tdebugfs_remove(ucsi_debugfs_root);\ndrivers/usb/typec/ucsi/debugfs.c-176-}\n--\ndrivers/usb/typec/ucsi/displayport.c-11-\ndrivers/usb/typec/ucsi/displayport.c:12:#include \"ucsi.h\"\ndrivers/usb/typec/ucsi/displayport.c-13-\n--\ndrivers/usb/typec/ucsi/displayport.c-17-\ndrivers/usb/typec/ucsi/displayport.c:18:struct ucsi_dp {\ndrivers/usb/typec/ucsi/displayport.c-19-\tstruct typec_displayport_data data;\ndrivers/usb/typec/ucsi/displayport.c:20:\tstruct ucsi_connector *con;\ndrivers/usb/typec/ucsi/displayport.c-21-\tstruct typec_altmode *alt;\n--\ndrivers/usb/typec/ucsi/displayport.c-47-\ndrivers/usb/typec/ucsi/displayport.c:48:static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\ndrivers/usb/typec/ucsi/displayport.c-49-{\ndrivers/usb/typec/ucsi/displayport.c:50:\tstruct ucsi_dp *dp = typec_altmode_get_drvdata(alt);\ndrivers/usb/typec/ucsi/displayport.c:51:\tstruct ucsi *ucsi = dp-\u003econ-\u003eucsi;\ndrivers/usb/typec/ucsi/displayport.c-52-\tint svdm_version;\n--\ndrivers/usb/typec/ucsi/displayport.c-56-\ndrivers/usb/typec/ucsi/displayport.c:57:\tif (!ucsi_con_mutex_lock(dp-\u003econ))\ndrivers/usb/typec/ucsi/displayport.c-58-\t\treturn -ENOTCONN;\n--\ndrivers/usb/typec/ucsi/displayport.c-69-\tcommand = UCSI_GET_CURRENT_CAM | UCSI_CONNECTOR_NUMBER(dp-\u003econ-\u003enum);\ndrivers/usb/typec/ucsi/displayport.c:70:\tret = ucsi_send_command(ucsi, command, \u0026cur, sizeof(cur));\ndrivers/usb/typec/ucsi/displayport.c-71-\tif (ret \u003c 0) {\ndrivers/usb/typec/ucsi/displayport.c:72:\t\tif (ucsi-\u003eversion \u003e 0x0100)\ndrivers/usb/typec/ucsi/displayport.c-73-\t\t\tgoto err_unlock;\n--\ndrivers/usb/typec/ucsi/displayport.c-106-err_unlock:\ndrivers/usb/typec/ucsi/displayport.c:107:\tucsi_con_mutex_unlock(dp-\u003econ);\ndrivers/usb/typec/ucsi/displayport.c-108-\n--\ndrivers/usb/typec/ucsi/displayport.c-111-\ndrivers/usb/typec/ucsi/displayport.c:112:static int ucsi_displayport_exit(struct typec_altmode *alt)\ndrivers/usb/typec/ucsi/displayport.c-113-{\ndrivers/usb/typec/ucsi/displayport.c:114:\tstruct ucsi_dp *dp = typec_altmode_get_drvdata(alt);\ndrivers/usb/typec/ucsi/displayport.c-115-\tint svdm_version;\n--\ndrivers/usb/typec/ucsi/displayport.c-118-\ndrivers/usb/typec/ucsi/displayport.c:119:\tif (!ucsi_con_mutex_lock(dp-\u003econ))\ndrivers/usb/typec/ucsi/displayport.c-120-\t\treturn -ENOTCONN;\n--\ndrivers/usb/typec/ucsi/displayport.c-131-\tcommand = UCSI_CMD_SET_NEW_CAM(dp-\u003econ-\u003enum, 0, dp-\u003eoffset, 0);\ndrivers/usb/typec/ucsi/displayport.c:132:\tret = ucsi_send_command(dp-\u003econ-\u003eucsi, command, NULL, 0);\ndrivers/usb/typec/ucsi/displayport.c-133-\tif (ret \u003c 0)\n--\ndrivers/usb/typec/ucsi/displayport.c-151-out_unlock:\ndrivers/usb/typec/ucsi/displayport.c:152:\tucsi_con_mutex_unlock(dp-\u003econ);\ndrivers/usb/typec/ucsi/displayport.c-153-\n--\ndrivers/usb/typec/ucsi/displayport.c-160- */\ndrivers/usb/typec/ucsi/displayport.c:161:static int ucsi_displayport_status_update(struct ucsi_dp *dp)\ndrivers/usb/typec/ucsi/displayport.c-162-{\n--\ndrivers/usb/typec/ucsi/displayport.c-188-\ndrivers/usb/typec/ucsi/displayport.c:189:static int ucsi_displayport_configure(struct ucsi_dp *dp)\ndrivers/usb/typec/ucsi/displayport.c-190-{\n--\ndrivers/usb/typec/ucsi/displayport.c-197-\n\n"
}

gemini-3.8-flash

null

null

							input: 46188
							output: 43
							thoughts: 755
						

**Analyzing the Reachability of UCSI for Fuzzing**

Okay, first things first, I need to figure out if syzkaller has any predefined descriptions or pseudo-devices related to UCSI or Type-C, but as the instructions clearly state, I can't use this tool for that. The tool's not set up to search syzkaller syzlang descriptions directly. It looks like I'm missing `read-syz-spec` and `syz-grepper` here anyway.

Alright, moving on. The core question is whether UCSI hardware is *reachable* in standard virtualized environments like GCE or QEMU, leveraging software-emulated devices. That's the primary hurdle – reachability. The criteria state that if code is structurally unreachable, it's a no-go for fuzzing. Specifically, structurally unreachable hardware like vendor-specific PCIe switches, SmartNICs, or GPU drivers are explicitly excluded if they require physical components not emulated in standard QEMU. Also unreachable execution paths are listed.

Now, let's delve into UCSI. Is UCSI structurally unreachable? What even *is* UCSI?

Based on the Kconfig description for `TYPEC_UCSI`, UCSI is an interface allowing the OS to control USB Type-C ports. On a UCSI system, the ports are autonomous initially, but the driver is crucial for status and operations like role swapping. The description points out UCSI is commonly found on newer Intel-based systems with Embedded Controllers and USB Type-C ports. Crucially, the interface method (ACPI, PCI, I2C, etc.) isn't defined by the UCSI spec itself, so drivers for each interface are necessary. So, this "driver" is core part of a wider system.

So, how does UCSI get instantiated? Let's check `drivers/usb/typec/ucsi/ucsi_acpi.c`. I need to review that to see how the software maps to the hardware.

{
  "File": "drivers/usb/typec/ucsi/ucsi_acpi.c",
  "FirstLine": 1,
  "LineCount": 80
}

{
  "Contents": "   1:\t// SPDX-License-Identifier: GPL-2.0\n   2:\t/*\n   3:\t * UCSI ACPI driver\n   4:\t *\n   5:\t * Copyright (C) 2017, Intel Corporation\n   6:\t * Author: Heikki Krogerus \u003cheikki.krogerus@linux.intel.com\u003e\n   7:\t */\n   8:\t\n   9:\t#include \u003clinux/platform_device.h\u003e\n  10:\t#include \u003clinux/module.h\u003e\n  11:\t#include \u003clinux/acpi.h\u003e\n  12:\t#include \u003clinux/dmi.h\u003e\n  13:\t\n  14:\t#include \"ucsi.h\"\n  15:\t\n  16:\t#define UCSI_DSM_UUID\t\t\"6f8398c2-7ca4-11e4-ad36-631042b5008f\"\n  17:\t#define UCSI_DSM_FUNC_WRITE\t1\n  18:\t#define UCSI_DSM_FUNC_READ\t2\n  19:\t\n  20:\tstruct ucsi_acpi {\n  21:\t\tstruct device *dev;\n  22:\t\tstruct ucsi *ucsi;\n  23:\t\tvoid *base;\n  24:\t\tbool check_bogus_event;\n  25:\t\tguid_t guid;\n  26:\t\tu64 cmd;\n  27:\t};\n  28:\t\n  29:\tstatic int ucsi_acpi_dsm(struct ucsi_acpi *ua, int func)\n  30:\t{\n  31:\t\tunion acpi_object *obj;\n  32:\t\n  33:\t\tobj = acpi_evaluate_dsm(ACPI_HANDLE(ua-\u003edev), \u0026ua-\u003eguid, 1, func,\n  34:\t\t\t\t\tNULL);\n  35:\t\tif (!obj) {\n  36:\t\t\tdev_err(ua-\u003edev, \"%s: failed to evaluate _DSM %d\\n\",\n  37:\t\t\t\t__func__, func);\n  38:\t\t\treturn -EIO;\n  39:\t\t}\n  40:\t\n  41:\t\tACPI_FREE(obj);\n  42:\t\treturn 0;\n  43:\t}\n  44:\t\n  45:\tstatic int ucsi_acpi_read_version(struct ucsi *ucsi, u16 *version)\n  46:\t{\n  47:\t\tstruct ucsi_acpi *ua = ucsi_get_drvdata(ucsi);\n  48:\t\tint ret;\n  49:\t\n  50:\t\tret = ucsi_acpi_dsm(ua, UCSI_DSM_FUNC_READ);\n  51:\t\tif (ret)\n  52:\t\t\treturn ret;\n  53:\t\n  54:\t\tmemcpy(version, ua-\u003ebase + UCSI_VERSION, sizeof(*version));\n  55:\t\n  56:\t\treturn 0;\n  57:\t}\n  58:\t\n  59:\tstatic int ucsi_acpi_read_cci(struct ucsi *ucsi, u32 *cci)\n  60:\t{\n  61:\t\tstruct ucsi_acpi *ua = ucsi_get_drvdata(ucsi);\n  62:\t\n  63:\t\tmemcpy(cci, ua-\u003ebase + UCSI_CCI, sizeof(*cci));\n  64:\t\n  65:\t\treturn 0;\n  66:\t}\n  67:\t\n  68:\tstatic int ucsi_acpi_poll_cci(struct ucsi *ucsi, u32 *cci)\n  69:\t{\n  70:\t\tstruct ucsi_acpi *ua = ucsi_get_drvdata(ucsi);\n  71:\t\tint ret;\n  72:\t\n  73:\t\tret = ucsi_acpi_dsm(ua, UCSI_DSM_FUNC_READ);\n  74:\t\tif (ret)\n  75:\t\t\treturn ret;\n  76:\t\n  77:\t\treturn ucsi_acpi_read_cci(ucsi, cci);\n  78:\t}\n  79:\t\n  80:\tstatic int ucsi_acpi_read_message_in(struct ucsi *ucsi, void *val, size_t val_len)\n"
}

gemini-3.8-flash

null

null

							input: 48538
							output: 45
							thoughts: 19
						

Here's my summary, as though I'm thinking it:

**Digging into the ACPI Match IDs in ucsi_acpi.c**

Alright, let's dive into the `ucsi_acpi.c` file and zero in on those ACPI match IDs. My goal here is to understand the hardware identification process for USB Type-C and UCSI controllers on ACPI-based systems. I'm assuming, based on the file name, that `ucsi_acpi.c` is the module responsible for handling UCSI (USB Type-C Connector System Software Interface) controllers when they're exposed through the ACPI (Advanced Configuration and Power Interface) interface. I need to figure out what specific ACPI IDs this driver recognizes and what kind of devices are being targeted. Understanding those IDs will tell me which specific hardware configurations this driver is designed to support. This is a critical first step in analyzing or debugging issues related to USB-C functionality on a given system. Let's see what we find.

{
  "File": "drivers/usb/typec/ucsi/ucsi_acpi.c",
  "FirstLine": 265,
  "LineCount": 40
}

{
  "Contents": " 265:\t\n 266:\tstatic int ucsi_acpi_suspend(struct device *dev)\n 267:\t{\n 268:\t\tstruct ucsi_acpi *ua = dev_get_drvdata(dev);\n 269:\t\n 270:\t\treturn ucsi_suspend(ua-\u003eucsi);\n 271:\t}\n 272:\t\n 273:\tstatic int ucsi_acpi_resume(struct device *dev)\n 274:\t{\n 275:\t\tstruct ucsi_acpi *ua = dev_get_drvdata(dev);\n 276:\t\n 277:\t\treturn ucsi_resume(ua-\u003eucsi);\n 278:\t}\n 279:\t\n 280:\tstatic DEFINE_SIMPLE_DEV_PM_OPS(ucsi_acpi_pm_ops, ucsi_acpi_suspend,\n 281:\t\t\t\t\tucsi_acpi_resume);\n 282:\t\n 283:\tstatic const struct acpi_device_id ucsi_acpi_match[] = {\n 284:\t\t{ \"PNP0CA0\", 0 },\n 285:\t\t{ },\n 286:\t};\n 287:\tMODULE_DEVICE_TABLE(acpi, ucsi_acpi_match);\n 288:\t\n 289:\tstatic struct platform_driver ucsi_acpi_platform_driver = {\n 290:\t\t.driver = {\n 291:\t\t\t.name = \"ucsi_acpi\",\n 292:\t\t\t.pm = pm_ptr(\u0026ucsi_acpi_pm_ops),\n 293:\t\t\t.acpi_match_table = ACPI_PTR(ucsi_acpi_match),\n 294:\t\t},\n 295:\t\t.probe = ucsi_acpi_probe,\n 296:\t\t.remove = ucsi_acpi_remove,\n 297:\t};\n 298:\t\n 299:\tmodule_platform_driver(ucsi_acpi_platform_driver);\n 300:\t\n 301:\tMODULE_AUTHOR(\"Heikki Krogerus \u003cheikki.krogerus@linux.intel.com\u003e\");\n 302:\tMODULE_LICENSE(\"GPL v2\");\n 303:\tMODULE_DESCRIPTION(\"UCSI ACPI driver\");\n"
}

gemini-3.8-flash

null

null

							input: 49449
							output: 24
							thoughts: 1294
						

**Analyzing UCSI Driver Landscape and Virtualization**

Okay, let's break this down. First, I need to understand the landscape of UCSI drivers. I see a range of implementations: `ucsi_acpi` for real ACPI devices (PNP0CA0) – which I know are Intel UCSI devices on physical hardware - `ucsi_ccg` for Cypress controllers over I2C, `ucsi_stm32g0` for STM32G0 controllers (also I2C), `ucsi_glink` for Qualcomm GLINK on mobile devices, `cros_ec_ucsi` for ChromeOS EC, and the Lenovo and Huawei EC implementations.

My immediate question: Is there *any* other driver, test module, or even an emulated driver that registers UCSI? Let me double-check. I'll search the kernel source for calls to `ucsi_create` or `ucsi_register`. Aha, the results are limited to the drivers I initially listed! No hidden gems or test harnesses that are registering this interface. The only entry points for the UCSI code paths are through these specific hardware-based drivers.

Now, let's explore related components. What about `typec_altmode_ops` or `displayport.c`? A quick look at the `Makefile` confirms `displayport.c` is linked into `typec_ucsi.ko` when `CONFIG_TYPEC_DP_ALTMODE` is enabled. It's clear that `ucsi_displayport_enter` is *only* used when a UCSI connector registers a DisplayPort alternate mode. That's called in `ucsi_register_altmode()` which is ultimately called by `ucsi_register_altmodes()` during `ucsi_init()`. Important point, for `ucsi_register()` to even *succeed* it demands a *real* UCSI device. `ucsi_acpi` demands an ACPI device with a valid `_DSM` method and shared memory base, responding to PPM commands. Likewise for the others.

So, the key is the underlying hardware. Now, can any of these real hardware dependencies exist in a standard virtualized environment? Does a generic QEMU or GCE instance even have a UCSI device, either emulated or otherwise?

Let's check. QEMU clearly has a plethora of emulated devices. Network, disk, USB, etc. But, does it emulate USB Type-C or UCSI? No, QEMU does not emulate UCSI (or PNP0CA0).

What about GCE? GCE VMs are KVM-based and run on Google's cloud infrastructure, typically using virtio devices. But, again, these machines do not have UCSI ACPI devices or physical Type-C connectors with DisplayPort alternate modes.

Finally, does syzkaller target or fuzz UCSI? A search for "ucsi" or "typec" in the kernel source, or syzkaller documentation, is needed to see if there are any virtual typec devices defined. Let's look for virtual or test drivers in `drivers/usb/typec`.

{
  "Dir": "drivers/usb/typec"
}

{
  "Files": [
    "anx7411.c",
    "bus.c",
    "bus.h",
    "class.c",
    "class.h",
    "hd3ss3220.c",
    "mode_selection.c",
    "mux.c",
    "mux.h",
    "pd.c",
    "pd.h",
    "port-mapper.c",
    "retimer.c",
    "retimer.h",
    "rt1719.c",
    "stusb160x.c",
    "wusb3801.c"
  ],
  "Subdirs": [
    "altmodes",
    "mux",
    "tcpm",
    "tipd",
    "ucsi"
  ]
}

gemini-3.8-flash

null

null

							input: 51616
							output: 27
							thoughts: 37
						

Here's my take on those thoughts:

**Navigating the USB Type-C TCPM Landscape**

Okay, hold on a second! I need to take a closer look at something. Specifically, I need to dive into the `drivers/usb/typec/tcpm/` directory. That's where the heart of the Type-C Port Manager (TCPM) implementations are, and it's essential for how USB-C power delivery and data roles are handled. Gotta see what's in there. Gotta understand the different TCPM implementations and how they're structured. This is the core of reliable USB-C functionality, and I need to make sure I'm up to speed on the latest changes and relevant details. Let's see what gems are hidden there.

{
  "Dir": "drivers/usb/typec/tcpm"
}

{
  "Files": [
    "fusb302.c",
    "fusb302_reg.h",
    "maxim_contaminant.c",
    "tcpci.c",
    "tcpci_maxim.h",
    "tcpci_maxim_core.c",
    "tcpci_mt6360.c",
    "tcpci_mt6370.c",
    "tcpci_rt1711h.c",
    "tcpm.c",
    "wcove.c"
  ],
  "Subdirs": [
    "qcom"
  ]
}

gemini-3.8-flash

null

null

							input: 51978
							output: 28
							thoughts: 35
						

**USB Gadget Inquiry**

Okay, hold on a second. I need to clarify something about this USB gadget scenario. Does the USB gadget functionality in the kernel, specifically, support Type-C? I need to know this definitively. To figure this out, let's dive into the code. I'm going to search for instances of "typec" within the USB gadget driver directory, which I know is located at `drivers/usb/gadget/`. That should give me a clear picture of its capabilities.

no matches

{
  "Expression": "typec",
  "PathPrefix": "drivers/usb/gadget"
}

{
  "error": "no matches"
}

gemini-3.8-flash

null

null

							input: 52163
							output: 19
							thoughts: 57
						

**My Initial Frustration and Investigative Path**

Okay, so this USB gadget I'm looking at, it's completely missing Type-C, which is immediately frustrating. But hold on, let's not jump to conclusions. I need to think systematically. My first instinct, and the usual place to start in this kind of situation, is to check the `drivers/usb/roles/` directory. Maybe the underlying framework is there, even if it's not immediately obvious. And, since it's an x86 based machine, I'll quickly glance over `drivers/platform/x86/`. It's a long shot, but worth the quick look.

If that doesn't pan out, it's time to dig deeper. Let's broaden the search. I should look for references to `PNP0CA0` or `ucsi` throughout the entire codebase. Those are key identifiers that could provide clues as to how this hardware is being handled at a lower level or potential driver implementations. That will be the next avenue to explore.

{
  "Expression": "PNP0CA0"
}

{
  "Output": "drivers/usb/typec/ucsi/ucsi_acpi.c=283=static const struct acpi_device_id ucsi_acpi_match[] = {\ndrivers/usb/typec/ucsi/ucsi_acpi.c:284:\t{ \"PNP0CA0\", 0 },\ndrivers/usb/typec/ucsi/ucsi_acpi.c-285-\t{ },\n"
}

gemini-3.8-flash

null

null

							input: 52579
							output: 29
							thoughts: 61
						

**Investigating USB Type-C Port Creation**

Okay, so I need to figure out if there's a way, a *supported* way, to create dummy USB Type-C ports through userspace. That functionality would be incredibly useful. First stop, let's dive into `drivers/usb/typec/class.c`. See if there are any hints or APIs in there. If that's not the right place, I'll switch gears and give the `Kconfig` files a look-over, specifically within the `drivers/usb/typec` directory. Configuration options often reveal a lot about potential functionality, even if it's not directly exposed through a dedicated interface. I am hoping to get a quick win, so let's start with the basics.

{
  "Expression": "config TYPEC",
  "PathPrefix": "drivers/usb/typec"
}

{
  "Output": "drivers/usb/typec/Kconfig-2-\ndrivers/usb/typec/Kconfig:3:menuconfig TYPEC\ndrivers/usb/typec/Kconfig-4-\ttristate \"USB Type-C Support\"\n--\ndrivers/usb/typec/Kconfig=53=source \"drivers/usb/typec/tipd/Kconfig\"\ndrivers/usb/typec/Kconfig-54-\ndrivers/usb/typec/Kconfig:55:config TYPEC_ANX7411\ndrivers/usb/typec/Kconfig-56-\ttristate \"Analogix ANX7411 Type-C DRP Port controller driver\"\n--\ndrivers/usb/typec/Kconfig-66-\ndrivers/usb/typec/Kconfig:67:config TYPEC_RT1719\ndrivers/usb/typec/Kconfig-68-\ttristate \"Richtek RT1719 Sink Only Type-C controller driver\"\n--\ndrivers/usb/typec/Kconfig-79-\ndrivers/usb/typec/Kconfig:80:config TYPEC_HD3SS3220\ndrivers/usb/typec/Kconfig-81-\ttristate \"TI HD3SS3220 Type-C DRP Port controller driver\"\n--\ndrivers/usb/typec/Kconfig-90-\ndrivers/usb/typec/Kconfig:91:config TYPEC_STUSB160X\ndrivers/usb/typec/Kconfig-92-\ttristate \"STMicroelectronics STUSB160x Type-C controller driver\"\n--\ndrivers/usb/typec/Kconfig-102-\ndrivers/usb/typec/Kconfig:103:config TYPEC_WUSB3801\ndrivers/usb/typec/Kconfig-104-\ttristate \"Willsemi WUSB3801 Type-C port controller driver\"\n--\ndrivers/usb/typec/altmodes/Kconfig=3=menu \"USB Type-C Alternate Mode drivers\"\ndrivers/usb/typec/altmodes/Kconfig-4-\ndrivers/usb/typec/altmodes/Kconfig:5:config TYPEC_DP_ALTMODE\ndrivers/usb/typec/altmodes/Kconfig-6-\ttristate \"DisplayPort Alternate Mode driver\"\n--\ndrivers/usb/typec/altmodes/Kconfig-16-\ndrivers/usb/typec/altmodes/Kconfig:17:config TYPEC_NVIDIA_ALTMODE\ndrivers/usb/typec/altmodes/Kconfig-18-\ttristate \"NVIDIA Alternate Mode driver\"\n--\ndrivers/usb/typec/altmodes/Kconfig-26-\ndrivers/usb/typec/altmodes/Kconfig:27:config TYPEC_TBT_ALTMODE\ndrivers/usb/typec/altmodes/Kconfig-28-\ttristate \"Thunderbolt3 Alternate Mode driver\"\n--\ndrivers/usb/typec/mux/Kconfig=3=menu \"USB Type-C Multiplexer/DeMultiplexer Switch support\"\ndrivers/usb/typec/mux/Kconfig-4-\ndrivers/usb/typec/mux/Kconfig:5:config TYPEC_MUX_FSA4480\ndrivers/usb/typec/mux/Kconfig-6-\ttristate \"ON Semi FSA4480 Analog Audio Switch driver\"\n--\ndrivers/usb/typec/mux/Kconfig-14-\ndrivers/usb/typec/mux/Kconfig:15:config TYPEC_MUX_GPIO_SBU\ndrivers/usb/typec/mux/Kconfig-16-\ttristate \"Generic GPIO based SBU mux for USB Type-C applications\"\n--\ndrivers/usb/typec/mux/Kconfig-20-\ndrivers/usb/typec/mux/Kconfig:21:config TYPEC_MUX_PI3USB30532\ndrivers/usb/typec/mux/Kconfig-22-\ttristate \"Pericom PI3USB30532 Type-C cross switch driver\"\n--\ndrivers/usb/typec/mux/Kconfig-27-\ndrivers/usb/typec/mux/Kconfig:28:config TYPEC_MUX_INTEL_PMC\ndrivers/usb/typec/mux/Kconfig-29-\ttristate \"Intel PMC mux control\"\n--\ndrivers/usb/typec/mux/Kconfig-38-\ndrivers/usb/typec/mux/Kconfig:39:config TYPEC_MUX_IT5205\ndrivers/usb/typec/mux/Kconfig-40-\ttristate \"ITE IT5205 Type-C USB Alt Mode Passive MUX driver\"\n--\ndrivers/usb/typec/mux/Kconfig-48-\ndrivers/usb/typec/mux/Kconfig:49:config TYPEC_MUX_NB7VPQ904M\ndrivers/usb/typec/mux/Kconfig-50-\ttristate \"On Semiconductor NB7VPQ904M Type-C redriver driver\"\n--\ndrivers/usb/typec/mux/Kconfig-58-\ndrivers/usb/typec/mux/Kconfig:59:config TYPEC_MUX_PS883X\ndrivers/usb/typec/mux/Kconfig-60-\ttristate \"Parade PS883x Type-C retimer driver\"\n--\ndrivers/usb/typec/mux/Kconfig-68-\ndrivers/usb/typec/mux/Kconfig:69:config TYPEC_MUX_PTN36502\ndrivers/usb/typec/mux/Kconfig-70-\ttristate \"NXP PTN36502 Type-C redriver driver\"\n--\ndrivers/usb/typec/mux/Kconfig-78-\ndrivers/usb/typec/mux/Kconfig:79:config TYPEC_MUX_TUSB1046\ndrivers/usb/typec/mux/Kconfig-80-\ttristate \"TI TUSB1046 Type-C crosspoint switch driver\"\n--\ndrivers/usb/typec/mux/Kconfig-87-\ndrivers/usb/typec/mux/Kconfig:88:config TYPEC_MUX_WCD939X_USBSS\ndrivers/usb/typec/mux/Kconfig-89-\ttristate \"Qualcomm WCD939x USBSS Analog Audio Switch driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig-2-\ndrivers/usb/typec/tcpm/Kconfig:3:config TYPEC_TCPM\ndrivers/usb/typec/tcpm/Kconfig-4-\ttristate \"USB Type-C Port Controller Manager\"\n--\ndrivers/usb/typec/tcpm/Kconfig=12=if TYPEC_TCPM\ndrivers/usb/typec/tcpm/Kconfig-13-\ndrivers/usb/typec/tcpm/Kconfig:14:config TYPEC_TCPCI\ndrivers/usb/typec/tcpm/Kconfig-15-\ttristate \"Type-C Port Controller Interface driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig=21=if TYPEC_TCPCI\ndrivers/usb/typec/tcpm/Kconfig-22-\ndrivers/usb/typec/tcpm/Kconfig:23:config TYPEC_RT1711H\ndrivers/usb/typec/tcpm/Kconfig-24-\ttristate \"Richtek RT1711H Type-C chip driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig-29-\ndrivers/usb/typec/tcpm/Kconfig:30:config TYPEC_MT6360\ndrivers/usb/typec/tcpm/Kconfig-31-\ttristate \"Mediatek MT6360 Type-C driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig-37-\ndrivers/usb/typec/tcpm/Kconfig:38:config TYPEC_TCPCI_MT6370\ndrivers/usb/typec/tcpm/Kconfig-39-\ttristate \"MediaTek MT6370 Type-C driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig-48-\ndrivers/usb/typec/tcpm/Kconfig:49:config TYPEC_TCPCI_MAXIM\ndrivers/usb/typec/tcpm/Kconfig-50-\ttristate \"Maxim TCPCI based Type-C chip driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig=55=endif # TYPEC_TCPCI\ndrivers/usb/typec/tcpm/Kconfig-56-\ndrivers/usb/typec/tcpm/Kconfig:57:config TYPEC_FUSB302\ndrivers/usb/typec/tcpm/Kconfig-58-\ttristate \"Fairchild FUSB302 Type-C chip driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig-67-\ndrivers/usb/typec/tcpm/Kconfig:68:config TYPEC_WCOVE\ndrivers/usb/typec/tcpm/Kconfig-69-\ttristate \"Intel WhiskeyCove PMIC USB Type-C PHY driver\"\n--\ndrivers/usb/typec/tcpm/Kconfig-80-\ndrivers/usb/typec/tcpm/Kconfig:81:config TYPEC_QCOM_PMIC\ndrivers/usb/typec/tcpm/Kconfig-82-\ttristate \"Qualcomm PMIC USB Type-C Port Controller Manager driver\"\n--\ndrivers/usb/typec/tipd/Kconfig:1:config TYPEC_TPS6598X\ndrivers/usb/typec/tipd/Kconfig-2-\ttristate \"TI TPS6598x USB Power Delivery controller driver\"\n--\ndrivers/usb/typec/ucsi/Kconfig-2-\ndrivers/usb/typec/ucsi/Kconfig:3:config TYPEC_UCSI\ndrivers/usb/typec/ucsi/Kconfig-4-\ttristate \"USB Type-C Connector System Software Interface driver\"\n"
}

gemini-3.8-flash

null

null

							input: 55290
							output: 34
							thoughts: 634
						

**My Assessment: UCSI Driver Fuzzing Feasibility**

Okay, let's break this down. My initial scan showed a list of physical chips and hardware components. None of those are virtual devices, so that's a red flag right away. I need to keep in mind the negative criteria for determining if something is worth fuzzing. I have to make sure that the code path I'm looking at isn't structurally unreachable, such as vendor-specific PCIe switches requiring physical hardware or code that only executes during PCI hot-unplug. If it's unreachable, it's a "no-go" for fuzzing.

My primary filter is reachability in standard virtualized environments. I'm focusing on GCE or QEMU, using their software-emulated devices. That's my baseline.

Now, let's get to the crucial question: Can UCSI hardware, specifically ACPI PNP0CA0, be executed in a standard virtualized environment like QEMU? And the answer is a resounding "no". QEMU doesn't emulate any UCSI device, nor does GCE have that hardware.

Alright, so I need to verify that there isn't some hidden UCSI emulator. Let's dig into the QEMU source code to confirm that QEMU doesn't have a UCSI device, or ACPI PNP0CA0. 

Just to be thorough, I have to check the Linux kernel itself. Is there *any* software emulation for UCSI lurking in the kernel? I'll look for "dummy," "mock," "virtual," or "test" drivers in the `drivers/usb/typec/` directory to make absolutely sure there's no way to reach this code in a standard environment.

{
  "Expression": "dummy|mock|virtual|test",
  "PathPrefix": "drivers/usb/typec/"
}

{
  "Output": "drivers/usb/typec/Kconfig=3=menuconfig TYPEC\n--\ndrivers/usb/typec/Kconfig-43-\t  Connector Class API (Documentation/driver-api/usb/typec.rst)\ndrivers/usb/typec/Kconfig:44:\t  \u003chttps://www.kernel.org/doc/html/latest/driver-api/usb/typec.html\u003e\ndrivers/usb/typec/Kconfig:45:\t  and ABI (Documentation/ABI/testing/sysfs-class-typec).\ndrivers/usb/typec/Kconfig-46-\n--\ndrivers/usb/typec/altmodes/Kconfig=17=config TYPEC_NVIDIA_ALTMODE\n--\ndrivers/usb/typec/altmodes/Kconfig-20-\thelp\ndrivers/usb/typec/altmodes/Kconfig:21:\t  Latest NVIDIA GPUs support VirtualLink devices. Select this\ndrivers/usb/typec/altmodes/Kconfig-22-\t  to enable support for VirtualLink devices with NVIDIA GPUs.\n--\ndrivers/usb/typec/anx7411.c=986=static irqreturn_t anx7411_intr_isr(int irq, void *data)\n--\ndrivers/usb/typec/anx7411.c-994-\ndrivers/usb/typec/anx7411.c:995:static int anx7411_register_i2c_dummy_clients(struct anx7411_data *ctx,\ndrivers/usb/typec/anx7411.c-996-\t\t\t\t\t      struct i2c_client *client)\n--\ndrivers/usb/typec/anx7411.c-1003-\t\t\tspi_addr = anx7411_i2c_addr[i].spi_address \u003e\u003e 1;\ndrivers/usb/typec/anx7411.c:1004:\t\t\tctx-\u003espi_client = i2c_new_dummy_device(client-\u003eadapter,\ndrivers/usb/typec/anx7411.c-1005-\t\t\t\t\t\t\t       spi_addr);\n--\ndrivers/usb/typec/anx7411.c=1462=static int anx7411_i2c_probe(struct i2c_client *client)\n--\ndrivers/usb/typec/anx7411.c-1479-\ndrivers/usb/typec/anx7411.c:1480:\tret = anx7411_register_i2c_dummy_clients(plat, client);\ndrivers/usb/typec/anx7411.c-1481-\tif (ret) {\n--\ndrivers/usb/typec/anx7411.c-1488-\t\tdev_err(dev, \"fail to probe typec switch\\n\");\ndrivers/usb/typec/anx7411.c:1489:\t\tgoto free_i2c_dummy;\ndrivers/usb/typec/anx7411.c-1490-\t}\n--\ndrivers/usb/typec/anx7411.c-1553-\ndrivers/usb/typec/anx7411.c:1554:free_i2c_dummy:\ndrivers/usb/typec/anx7411.c-1555-\ti2c_unregister_device(plat-\u003espi_client);\n--\ndrivers/usb/typec/mux/ps883x.c=366=static int ps883x_retimer_probe(struct i2c_client *client)\n--\ndrivers/usb/typec/mux/ps883x.c-428-\t/* skip resetting if already configured */\ndrivers/usb/typec/mux/ps883x.c:429:\tif (regmap_test_bits(retimer-\u003eregmap, REG_USB_PORT_CONN_STATUS_0,\ndrivers/usb/typec/mux/ps883x.c-430-\t\t\t     CONN_STATUS_0_CONNECTION_PRESENT) == 1) {\n--\ndrivers/usb/typec/tcpm/tcpm.c=427=struct pd_identifier {\n--\ndrivers/usb/typec/tcpm/tcpm.c-437- * @load_char: Snk overload characteristics\ndrivers/usb/typec/tcpm/tcpm.c:438: * @compliance: Types of sources the sink has been tested \u0026 certified on\ndrivers/usb/typec/tcpm/tcpm.c-439- * @modes: Charging caps \u0026 power sources supported\n--\ndrivers/usb/typec/tipd/core.c=1535=static int tps25750_complete_patch_process(struct tps6598x *tps)\n--\ndrivers/usb/typec/tipd/core.c-1538-\tu8 out_data[40];\ndrivers/usb/typec/tipd/core.c:1539:\tu8 dummy[2] = { };\ndrivers/usb/typec/tipd/core.c-1540-\n--\ndrivers/usb/typec/tipd/core.c-1544-\t */\ndrivers/usb/typec/tipd/core.c:1545:\tret = tps6598x_exec_cmd_tmo(tps, \"PBMc\", sizeof(dummy), dummy,\ndrivers/usb/typec/tipd/core.c-1546-\t\t\t\t    sizeof(out_data), out_data, 2000, 20);\n--\ndrivers/usb/typec/ucsi/ucsi.c=40=void ucsi_notify_common(struct ucsi *ucsi, u32 cci)\n--\ndrivers/usb/typec/ucsi/ucsi.c-55-\tif (cci \u0026 UCSI_CCI_ACK_COMPLETE \u0026\u0026\ndrivers/usb/typec/ucsi/ucsi.c:56:\t    test_and_clear_bit(ACK_PENDING, \u0026ucsi-\u003eflags))\ndrivers/usb/typec/ucsi/ucsi.c-57-\t\tcomplete(\u0026ucsi-\u003ecomplete);\n--\ndrivers/usb/typec/ucsi/ucsi.c-59-\tif (cci \u0026 UCSI_CCI_COMMAND_COMPLETE \u0026\u0026\ndrivers/usb/typec/ucsi/ucsi.c:60:\t    test_and_clear_bit(COMMAND_PENDING, \u0026ucsi-\u003eflags))\ndrivers/usb/typec/ucsi/ucsi.c-61-\t\tcomplete(\u0026ucsi-\u003ecomplete);\n--\ndrivers/usb/typec/ucsi/ucsi.c=1445=static void ucsi_handle_connector_change(struct work_struct *work)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1457-\ndrivers/usb/typec/ucsi/ucsi.c:1458:\tif (!test_and_set_bit(EVENT_PENDING, \u0026ucsi-\u003eflags))\ndrivers/usb/typec/ucsi/ucsi.c-1459-\t\tdev_err_once(ucsi-\u003edev, \"%s entered without EVENT_PENDING\\n\",\n--\ndrivers/usb/typec/ucsi/ucsi.c=1559=void ucsi_connector_change(struct ucsi *ucsi, u8 num)\n--\ndrivers/usb/typec/ucsi/ucsi.c-1576-\ndrivers/usb/typec/ucsi/ucsi.c:1577:\tif (!test_and_set_bit(EVENT_PENDING, \u0026ucsi-\u003eflags))\ndrivers/usb/typec/ucsi/ucsi.c-1578-\t\tschedule_work(\u0026con-\u003ework);\n--\ndrivers/usb/typec/ucsi/ucsi.h=476=struct ucsi {\n--\ndrivers/usb/typec/ucsi/ucsi.h-497-\ndrivers/usb/typec/ucsi/ucsi.h:498:\t/* The latest \"Notification Enable\" bits (SET_NOTIFICATION_ENABLE) */\ndrivers/usb/typec/ucsi/ucsi.h-499-\tu64 ntfy;\n--\ndrivers/usb/typec/ucsi/ucsi.h=655=static inline void ucsi_debugfs_unregister(struct ucsi *ucsi) { }\n--\ndrivers/usb/typec/ucsi/ucsi.h-659- * NVIDIA VirtualLink (svid 0x955) has two altmode. VirtualLink\ndrivers/usb/typec/ucsi/ucsi.h:660: * DP mode with vdo=0x1 and NVIDIA test mode with vdo=0x3\ndrivers/usb/typec/ucsi/ucsi.h-661- */\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=477=static void ucsi_ccg_update_set_new_cam_cmd(struct ucsi_ccg *uc,\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-536-/*\ndrivers/usb/typec/ucsi/ucsi_ccg.c:537: * Change the order of vdo values of NVIDIA test device FTB\ndrivers/usb/typec/ucsi/ucsi_ccg.c-538- * (Function Test Board) which reports altmode list with vdo=0x3\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=756=static void ccg_process_response(struct ucsi_ccg *uc)\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-761-\t\tif (uc-\u003edev_resp.code == RESET_COMPLETE) {\ndrivers/usb/typec/ucsi/ucsi_ccg.c:762:\t\t\tif (test_bit(RESET_PENDING, \u0026uc-\u003eflags))\ndrivers/usb/typec/ucsi/ucsi_ccg.c-763-\t\t\t\tuc-\u003ecmd_resp = uc-\u003edev_resp.code;\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-769-\t} else {\ndrivers/usb/typec/ucsi/ucsi_ccg.c:770:\t\tif (test_bit(DEV_CMD_PENDING, \u0026uc-\u003eflags)) {\ndrivers/usb/typec/ucsi/ucsi_ccg.c-771-\t\t\tuc-\u003ecmd_resp = uc-\u003edev_resp.code;\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=1109=static int ccg_fw_update_needed(struct ucsi_ccg *uc,\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1147-\t} else {\ndrivers/usb/typec/ucsi/ucsi_ccg.c:1148:\t\tdev_info(dev, \"secondary and primary fw are the latest\\n\");\ndrivers/usb/typec/ucsi/ucsi_ccg.c-1149-\t\t*mode = FLASH_NOT_NEEDED;\n--\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c=570=static int ucsi_stm32g0_probe_bootloader(struct ucsi *ucsi)\n--\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-584-\t\t/* STM32G0 in bootloader mode communicates at reserved address 0x51 */\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c:585:\t\tg0-\u003ei2c_bl = i2c_new_dummy_device(g0-\u003eclient-\u003eadapter, STM32G0_I2C_BL_ADDR);\ndrivers/usb/typec/ucsi/ucsi_stm32g0.c-586-\t\tif (IS_ERR(g0-\u003ei2c_bl)) {\n--\ndrivers/usb/typec/wusb3801.c=300=static irqreturn_t wusb3801_irq(int irq, void *data)\n--\ndrivers/usb/typec/wusb3801.c-302-\tstruct wusb3801 *wusb3801 = data;\ndrivers/usb/typec/wusb3801.c:303:\tunsigned int dummy;\ndrivers/usb/typec/wusb3801.c-304-\n--\ndrivers/usb/typec/wusb3801.c-308-\t */\ndrivers/usb/typec/wusb3801.c:309:\tregmap_read(wusb3801-\u003eregmap, WUSB3801_REG_INT, \u0026dummy);\ndrivers/usb/typec/wusb3801.c-310-\n"
}

gemini-3.8-flash

null

null

							input: 59568
							output: 36
							thoughts: 63
						

**My Initial Assessment and Investigative Approach**

Okay, so there aren't any readily available mock or virtual Type-C controllers. That's a bit of a hurdle. But hold on, let's not jump to conclusions. Before I start down a path of creating something from scratch, a good first step, as always, is to check known sources of truth. I need to see if syzkaller has ever found anything interesting in the **ucsi** driver or any files under `drivers/usb/typec/ucsi`. Bug reports are a goldmine for understanding potential vulnerabilities or areas that might need closer scrutiny. If there's a history, it could inform my next steps, and reveal prior efforts. Now, let me dive into that git log specifically for the `drivers/usb/typec/ucsi/` directory to see what I can find.

no matches

{
  "Expression": "syzkaller|syzbot",
  "PathPrefix": "drivers/usb/typec/ucsi"
}

{
  "error": "no matches"
}

gemini-3.8-flash

null

null

							input: 59862
							output: 33
							thoughts: 49
						

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

**USB Type-C UCSI Driver - Zero Syzkaller Finds? Hmm...**

Alright, that's odd. I ran a quick search within the `drivers/usb/typec/ucsi` directory, specifically looking for mentions of `syzkaller` or `syzbot`, and got *nothing*. No matches, not even a peep. That's unusual, especially given the importance of those tools for fuzzing and catching potential bugs in drivers.

My immediate next step is to broaden the scope. I need to see if this is just a UCSI-specific issue, or if there's something more general going on within the entire `drivers/usb/typec/` subsystem. I'm going to re-run the search, but this time covering the entire `drivers/usb/typec/` directory. Perhaps the relevant entries are elsewhere within the Type-C umbrella, maybe in a related component or in some common utility functions utilized by multiple drivers in the subsystem. Gotta be thorough. Let's see what turns up.

no matches

{
  "Expression": "syzkaller|syzbot",
  "PathPrefix": "drivers/usb/typec"
}

{
  "error": "no matches"
}

gemini-3.8-flash

null

null

							input: 60196
							output: 41
							thoughts: 611
						

**My Analysis of the USB Type-C/UCSI Driver Absence**

Okay, I see the problem. I'm looking at `drivers/usb/typec` and getting absolutely zero hits. That's immediately suspicious. This is because USB Type-C controllers, specifically UCSI (USB Type-C Connector System Software Interface), are fundamentally tied to *physical* hardware. They require a real UCSI implementation, which usually resides in an Embedded Controller (EC) or a dedicated hardware controller on the platform. The OS communicates with this PPM (Platform Policy Manager) via ACPI, I2C, or mailbox interfaces.

Crucially, standard virtualized environments like QEMU or Google Compute Engine simply *do not* emulate the UCSI hardware or Type-C controllers. There are no virtual UCSI devices present, meaning the driver will fail to probe or initialize because it can't interact with physical hardware that would respond to the low-level PPM transactions.

Furthermore, I understand now that the `ucsi_displayport_enter` function specifically addresses the alternate-mode callback that gets triggered when a connected Type-C DisplayPort partner device is entering DisplayPort alternate mode on a UCSI port. The context here is the interplay of physical hardware and alternate mode functionality.

Now, let's see if I can figure out what change this is about. I'll check the commit message. No `git log`? Fine, I have the diff. Let's look at the `drivers/usb/typec/ucsi/displayport.c` around line 71.

Okay, here's what the diff shows:
```diff
--- a/drivers/usb/typec/ucsi/displayport.c
+++ b/drivers/usb/typec/ucsi/displayport.c
@@ -71,11 +71,14 @@ static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)
 	if (ret < 0) {
 		if (ucsi->version > 0x0100)
 			goto err_unlock;
-		cur = 0xff;
 	}
 
-	if (cur < UCSI_MAX_ALTMODES) {
-		ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY;
+	if (cur != 0xff) {
+		if (cur < UCSI_MAX_ALTMODES)
+			ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY;
+		else
+			ret = -EINVAL;
+
 		goto err_unlock;
 	}
 ```
It seems like there's a correction to how `cur` is handled within the code, and how that value is compared. This is good, I should be able to figure out the original commit.

{
  "File": "drivers/usb/typec/ucsi/displayport.c",
  "FirstLine": 48,
  "LineCount": 55
}

{
  "Contents": "  48:\tstatic int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\n  49:\t{\n  50:\t\tstruct ucsi_dp *dp = typec_altmode_get_drvdata(alt);\n  51:\t\tstruct ucsi *ucsi = dp-\u003econ-\u003eucsi;\n  52:\t\tint svdm_version;\n  53:\t\tu64 command;\n  54:\t\tu8 cur = 0;\n  55:\t\tint ret;\n  56:\t\n  57:\t\tif (!ucsi_con_mutex_lock(dp-\u003econ))\n  58:\t\t\treturn -ENOTCONN;\n  59:\t\n  60:\t\tif (!dp-\u003eoverride \u0026\u0026 dp-\u003einitialized) {\n  61:\t\t\tconst struct typec_altmode *p = typec_altmode_get_partner(alt);\n  62:\t\n  63:\t\t\tdev_warn(\u0026p-\u003edev,\n  64:\t\t\t\t \"firmware doesn't support alternate mode overriding\\n\");\n  65:\t\t\tret = -EOPNOTSUPP;\n  66:\t\t\tgoto err_unlock;\n  67:\t\t}\n  68:\t\n  69:\t\tcommand = UCSI_GET_CURRENT_CAM | UCSI_CONNECTOR_NUMBER(dp-\u003econ-\u003enum);\n  70:\t\tret = ucsi_send_command(ucsi, command, \u0026cur, sizeof(cur));\n  71:\t\tif (ret \u003c 0) {\n  72:\t\t\tif (ucsi-\u003eversion \u003e 0x0100)\n  73:\t\t\t\tgoto err_unlock;\n  74:\t\t}\n  75:\t\n  76:\t\tif (cur != 0xff) {\n  77:\t\t\tif (cur \u003c UCSI_MAX_ALTMODES)\n  78:\t\t\t\tret = dp-\u003econ-\u003eport_altmode[cur] == alt ? 0 : -EBUSY;\n  79:\t\t\telse\n  80:\t\t\t\tret = -EINVAL;\n  81:\t\n  82:\t\t\tgoto err_unlock;\n  83:\t\t}\n  84:\t\n  85:\t\t/*\n  86:\t\t * We can't send the New CAM command yet to the PPM as it needs the\n  87:\t\t * configuration value as well. Pretending that we have now entered the\n  88:\t\t * mode, and letting the alt mode driver continue.\n  89:\t\t */\n  90:\t\n  91:\t\tsvdm_version = typec_altmode_get_svdm_version(alt);\n  92:\t\tif (svdm_version \u003c 0) {\n  93:\t\t\tret = svdm_version;\n  94:\t\t\tgoto err_unlock;\n  95:\t\t}\n  96:\t\n  97:\t\tdp-\u003eheader = VDO(USB_TYPEC_DP_SID, 1, svdm_version, CMD_ENTER_MODE);\n  98:\t\tdp-\u003eheader |= VDO_OPOS(USB_TYPEC_DP_MODE);\n  99:\t\tdp-\u003eheader |= VDO_CMDT(CMDT_RSP_ACK);\n 100:\t\n 101:\t\tdp-\u003evdo_data = NULL;\n 102:\t\tdp-\u003evdo_size = 1;\n"
}

gemini-3.8-flash

null

null

							input: 62325
							output: 37
							thoughts: 367
						

**Analyzing the UCSI Code Snippet**

Okay, let's break this down. Before this patch, the code was doing something like this: after sending a command via `ucsi_send_command` and receiving a value for `cur`, we have a potential problem. If the returned `cur` value is greater than or equal to `UCSI_MAX_ALTMODES`, we would have a logic error.

Specifically, the code was vulnerable to a couple of scenarios. First, if `ucsi_send_command` returned `0xff`, indicating no alternate mode was active, the code would proceed as though it *was* in a valid alternate mode. The comparison `cur < UCSI_MAX_ALTMODES` would be false. Second, if `cur` held a value larger than `UCSI_MAX_ALTMODES`, let's say 5 while the maximum number of altmodes allowed is 4, then the same check would fail and we'd run into problems down the line.

The UCSI specification indicates `0xff` signifies no active alternate mode, which is correct. However, if the `ucsi_send_command` did succeed and returned `0xff` or if it did succeed and returned an invalid altmode index (like 5), the code wouldn't jump to the error handling path (`err_unlock`). It would instead continue, likely leading to incorrect behavior when trying to enter DP mode. So the problem is handling those edge cases where the returned index is invalid or represents no active altmode.

I need to confirm what the value of `UCSI_MAX_ALTMODES` is to fully understand the logic here. A quick grep should reveal that.

{
  "Expression": "UCSI_MAX_ALTMODES",
  "PathPrefix": "drivers/usb/typec/ucsi"
}

{
  "Output": "drivers/usb/typec/ucsi/displayport.c=48=static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)\n--\ndrivers/usb/typec/ucsi/displayport.c-76-\tif (cur != 0xff) {\ndrivers/usb/typec/ucsi/displayport.c:77:\t\tif (cur \u003c UCSI_MAX_ALTMODES)\ndrivers/usb/typec/ucsi/displayport.c-78-\t\t\tret = dp-\u003econ-\u003eport_altmode[cur] == alt ? 0 : -EBUSY;\n--\ndrivers/usb/typec/ucsi/thunderbolt.c=81=static int ucsi_thunderbolt_enter(struct typec_altmode *alt, u32 *vdo)\n--\ndrivers/usb/typec/ucsi/thunderbolt.c-100-\tif (cur != 0xff) {\ndrivers/usb/typec/ucsi/thunderbolt.c:101:\t\tif (cur \u003e= UCSI_MAX_ALTMODES || con-\u003eport_altmode[cur] != alt)\ndrivers/usb/typec/ucsi/thunderbolt.c-102-\t\t\tret = -EBUSY;\n--\ndrivers/usb/typec/ucsi/ucsi.c=354=void ucsi_altmode_update_active(struct ucsi_connector *con)\n--\ndrivers/usb/typec/ucsi/ucsi.c-373-\ndrivers/usb/typec/ucsi/ucsi.c:374:\tif (cur \u003c UCSI_MAX_ALTMODES)\ndrivers/usb/typec/ucsi/ucsi.c-375-\t\taltmode = typec_altmode_get_partner(con-\u003eport_altmode[cur]);\n--\ndrivers/usb/typec/ucsi/ucsi.c=402=static int ucsi_next_altmode(struct typec_altmode **alt)\n--\ndrivers/usb/typec/ucsi/ucsi.c-405-\ndrivers/usb/typec/ucsi/ucsi.c:406:\tfor (i = 0; i \u003c UCSI_MAX_ALTMODES; i++)\ndrivers/usb/typec/ucsi/ucsi.c-407-\t\tif (!alt[i])\n--\ndrivers/usb/typec/ucsi/ucsi.c=413=static int ucsi_get_num_altmode(struct typec_altmode **alt)\n--\ndrivers/usb/typec/ucsi/ucsi.c-416-\ndrivers/usb/typec/ucsi/ucsi.c:417:\tfor (i = 0; i \u003c UCSI_MAX_ALTMODES; i++)\ndrivers/usb/typec/ucsi/ucsi.c-418-\t\tif (!alt[i])\n--\ndrivers/usb/typec/ucsi/ucsi.c=556=static int ucsi_altmode_count_svid(struct typec_altmode **altmodes, u16 svid)\n--\ndrivers/usb/typec/ucsi/ucsi.c-560-\ndrivers/usb/typec/ucsi/ucsi.c:561:\tfor (k = 0; k \u003c UCSI_MAX_ALTMODES; k++) {\ndrivers/usb/typec/ucsi/ucsi.c-562-\t\tif (!altmodes[k])\n--\ndrivers/usb/typec/ucsi/ucsi.c=596=static bool ucsi_altmode_is_duplicate(struct ucsi_connector *con, u8 recipient,\n--\ndrivers/usb/typec/ucsi/ucsi.c-640-\t/* CON and SOP_P: drop only exact SVID+VDO duplicates. */\ndrivers/usb/typec/ucsi/ucsi.c:641:\tfor (k = 0; k \u003c UCSI_MAX_ALTMODES; k++) {\ndrivers/usb/typec/ucsi/ucsi.c-642-\t\tif (!altmodes[k])\n--\ndrivers/usb/typec/ucsi/ucsi.c=657=ucsi_register_altmodes_nvidia(struct ucsi_connector *con, u8 recipient)\ndrivers/usb/typec/ucsi/ucsi.c-658-{\ndrivers/usb/typec/ucsi/ucsi.c:659:\tint max_altmodes = UCSI_MAX_ALTMODES;\ndrivers/usb/typec/ucsi/ucsi.c-660-\tstruct typec_altmode_desc desc;\ndrivers/usb/typec/ucsi/ucsi.c-661-\tstruct ucsi_altmode alt;\ndrivers/usb/typec/ucsi/ucsi.c:662:\tstruct ucsi_altmode orig[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi.c:663:\tstruct ucsi_altmode updated[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi.c-664-\tstruct ucsi *ucsi = con-\u003eucsi;\n--\ndrivers/usb/typec/ucsi/ucsi.c=737=static int ucsi_register_altmodes(struct ucsi_connector *con, u8 recipient)\ndrivers/usb/typec/ucsi/ucsi.c-738-{\ndrivers/usb/typec/ucsi/ucsi.c:739:\tint max_altmodes = UCSI_MAX_ALTMODES;\ndrivers/usb/typec/ucsi/ucsi.c-740-\tstruct typec_altmode_desc desc;\n--\ndrivers/usb/typec/ucsi/ucsi.h=476=struct ucsi {\n--\ndrivers/usb/typec/ucsi/ucsi.h-521-#define UCSI_MAX_SVID\t\t5\ndrivers/usb/typec/ucsi/ucsi.h:522:#define UCSI_MAX_ALTMODES\t(UCSI_MAX_SVID * 6)\ndrivers/usb/typec/ucsi/ucsi.h-523-\n--\ndrivers/usb/typec/ucsi/ucsi.h=529=struct ucsi_connector {\n--\ndrivers/usb/typec/ucsi/ucsi.h-544-\ndrivers/usb/typec/ucsi/ucsi.h:545:\tstruct typec_altmode *port_altmode[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi.h:546:\tstruct typec_altmode *partner_altmode[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi.h:547:\tstruct typec_altmode *plug_altmode[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi.h-548-\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=202=struct ucsi_ccg {\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-226-\tbool has_multiple_dp;\ndrivers/usb/typec/ucsi/ucsi_ccg.c:227:\tstruct ucsi_ccg_altmode orig[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi_ccg.c:228:\tstruct ucsi_ccg_altmode updated[UCSI_MAX_ALTMODES];\ndrivers/usb/typec/ucsi/ucsi_ccg.c-229-\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c=397=static bool ucsi_ccg_update_altmodes(struct ucsi *ucsi,\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-418-\t */\ndrivers/usb/typec/ucsi/ucsi_ccg.c:419:\tfor (i = 0; i \u003c UCSI_MAX_ALTMODES; i++) {\ndrivers/usb/typec/ucsi/ucsi_ccg.c-420-\t\talt[i].svid = orig[i].svid;\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-425-\ndrivers/usb/typec/ucsi/ucsi_ccg.c:426:\tfor (i = 0; i \u003c UCSI_MAX_ALTMODES; i++) {\ndrivers/usb/typec/ucsi/ucsi_ccg.c-427-\t\tif (!alt[i].svid)\n--\ndrivers/usb/typec/ucsi/ucsi_ccg.c-445-\ndrivers/usb/typec/ucsi/ucsi_ccg.c:446:\t\tfor (j = i + 1; j \u003c UCSI_MAX_ALTMODES; j++) {\ndrivers/usb/typec/ucsi/ucsi_ccg.c-447-\t\t\tif (alt[i].svid != alt[j].svid ||\n"
}

gemini-3.8-flash

null

null

							input: 65396
							output: 175
							thoughts: 2155
						

**Analysis of USB Type-C UCSI DisplayPort Driver Patch Reachability for Fuzzing**

Okay, let's break this down. I've got a patch here that seems to fix a potential bug in the DisplayPort alternate mode handling within the UCSI (USB Type-C System Control Interface) driver. The bug stems from an incorrect index check (`cur`) that could potentially lead to bypassing the DisplayPort entry sequence if the UCSI firmware returned an invalid index or on older UCSI versions. The patch now handles these cases correctly, returning an error (`-EINVAL`) in the invalid index scenario.

The question now is, is this code, the *fixed* code, reachable by fuzzing? We have to determine if it can be reached in standard virtualized environments like QEMU or GCE.

First, I reviewed the code's call paths. The key function is `ucsi_displayport_enter`, and it's called through a `typec_altmode_ops` structure. This structure is initialized and registered through `ucsi_register_displayport` called from `ucsi_register`, so, UCSI controller must be probed and registered first, and then it must support DisplayPort alternate mode.

To get there, we need a UCSI PPM instance. The only places that `ucsi_create` is called are, in a variety of hardware-specific drivers: cros_ec_ucsi, ucsi_acpi, ucsi_ccg, ucsi_glink, ucsi_huawei_gaokun, ucsi_stm32g0, and ucsi_yoga_c630, which are hardware controllers. Now, none of these drivers are going to probe without the physical hardware, or without the proper firmware running and responding to driver interactions. The drivers interact directly with the hardware through device-specific mechanisms (e.g., I2C reads/writes, ACPI methods, or cros_ec host commands). Even *if* we could create a platform device or I2C client via sysfs (which seems unlikely), the probe routines immediately communicate with this hardware. If the physical hardware/firmware isn't present, the probe fails and `ucsi_register` isn't called. We also need the PPM to report connectors, report altmodes with USB_TYPEC_DP_SID to register DisplayPort altmode via `ucsi_register_displayport`, and then an enter altmode request has to be issued, which is all hardware specific.

Given that these UCSI controllers require physical hardware/firmware that isn't emulated in standard QEMU or GCE, this code is structurally unreachable from a fuzzing perspective. It falls under the category of "Structurally unreachable hardware... requiring physical ASIC/PCIe cards not emulated in standard QEMU". Therefore, fuzzing this patched code would be a waste of resources.

So, the `WorthFuzzing` flag is `false`. The `EnableConfigs` will be `null` and the `FocusSymbols` will be `null`. The `Reasoning` is that the code targets hardware controllers that are not emulated in standard QEMU or GCE. This means that the patch is unreachable in standard virtualized fuzzing environments.

missing argument "FocusSymbols"

{
  "EnableConfigs": null,
  "FocusSymbols": null,
  "Reasoning": "The modified function `ucsi_displayport_enter` is part of the UCSI (USB Type-C Connector System Software Interface) DisplayPort alternate mode driver. UCSI drivers (such as ucsi_acpi, ucsi_ccg, cros_ec_ucsi, and ucsi_stm32g0) require physical platform hardware (such as physical ACPI PPM devices, ChromeOS EC, or external I2C Type-C controllers) that are not emulated in standard virtualized fuzzing environments (QEMU or GCE). Because there is no software emulation or mock driver for UCSI, the modified code is structurally unreachable during fuzzing.",
  "WorthFuzzing": false
}

{
  "error": "missing argument \"FocusSymbols\""
}

gemini-3.8-flash

null

null

### SUMMARY OF INVESTIGATION

#### 1. Approaches Tried & Results
- **Patch Inspection**:
  - Target commit: `4ca8974368a792bb757c49e63d1c02338479db3f`
  - File: `drivers/usb/typec/ucsi/displayport.c`
  - Function: `ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)`
  - Diff analysis:
    - Previously, when `ucsi_send_command(ucsi, command, &cur, sizeof(cur))` failed with `ret < 0` and `ucsi->version <= 0x0100`, it set `cur = 0xff;`.
    - Check was `if (cur < UCSI_MAX_ALTMODES) ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY; goto err_unlock;`.
    - Now: `cur = 0xff` assignment was removed. Check changed to `if (cur != 0xff) { if (cur < UCSI_MAX_ALTMODES) ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY; else ret = -EINVAL; goto err_unlock; }`.
    - Prevents out-of-bounds indexing or improper handling if `cur >= UCSI_MAX_ALTMODES` and not `0xff`.
- **Call Chain / Entrypoint Analysis**:
  - `ucsi_displayport_enter` is registered in `ucsi_displayport_ops.enter` (`drivers/usb/typec/ucsi/displayport.c:277`).
  - Called via `typec_altmode_ops.enter`:
    - `typec_altmode_enter()` (`drivers/usb/typec/bus.c:147`)
    - Called from `drivers/usb/typec/altmodes/displayport.c` (`dp_altmode_work`, `dp_altmode_activate`).
    - Sysfs attribute `active` on typec altmode (`drivers/usb/typec/class.c:398` -> `adev->ops->activate(adev, enter)` -> `typec_altmode_enter`).
- **Subsystem & Driver Instantiation Analysis**:
  - Checked what instantiates UCSI instances via `ucsi_create` and `ucsi_register`:
    - `drivers/usb/typec/ucsi/cros_ec_ucsi.c`: ChromeOS EC (requires `MFD_CROS_EC_DEV`, `CROS_USBPD_NOTIFY`, ACPI ID "GOOG0021" or OF compatible "google,cros-ec-ucsi").
    - `drivers/usb/typec/ucsi/ucsi_acpi.c`: ACPI device (`ACPI` PNP0CA0 / USBC000).
    - `drivers/usb/typec/ucsi/ucsi_ccg.c`: Cypress CCGx I2C device (requires I2C hardware / communication in probe).
    - `drivers/usb/typec/ucsi/ucsi_stm32g0.c`: STM32G0 I2C device (requires I2C hardware / communication in probe).
    - `drivers/usb/typec/ucsi/ucsi_glink.c`: Qualcomm PMIC GLINK auxiliary device.
    - `drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c`: Huawei auxiliary device.
    - `drivers/usb/typec/ucsi/ucsi_yoga_c630.c`: Lenovo Yoga C630 auxiliary device.
  - Investigated if any virtual UCSI / mock PPM / USB gadget UCSI exists in standard kernel or QEMU: none found in standard kernel drivers tree.

#### 2. Hypotheses & Active Lines of Investigation
- **Reachability in Virtualized Environments (QEMU / Syzkaller)**:
  - Is `drivers/usb/typec/ucsi/` reachable in standard syzkaller / QEMU test environments?
  - Need to verify whether UCSI devices can be instantiated purely via software emulation (e.g., USB raw gadget, dummy_hcd, mock platform device, or dynamic ACPI/I2C instantiation via sysfs):
    - I2C instantiation via `/sys/bus/i2c/devices/i2c-X/new_device`: probe fails immediately on I/O error (`ucsi_ccg_init` or `ucsi_stm32g0_probe_bootloader`) unless emulated hardware responds.
    - ACPI / Platform: QEMU standard x86 BIOS/ACPI tables do not expose UCSI PPM ACPI devices (`PNP0CA0` or `USBC000`).
    - Syzkaller fuzzes USB via Dummy HCD / Raw Gadget (`/dev/raw-gadget`), which emulates USB *devices* and *hosts*, but UCSI represents an interface between the OS and the system's USB Type-C Platform Policy Manager (PPM), typically implemented in system firmware/EC or discrete I2C chips.
    - Without a UCSI PPM device registered, `ucsi_register_port()`, `ucsi_register_altmode()`, and `ucsi_register_displayport()` will never be called, leaving `ucsi_displayport_enter()` unreachable.
- Need to check if there is any virtual UCSI driver or test module in the kernel tree (e.g., under `drivers/usb/typec/ucsi/` or elsewhere) before deciding `WorthFuzzing`.

#### 3. Critical Code Snippets & File Paths
- **File**: `drivers/usb/typec/ucsi/displayport.c`
```c
static int ucsi_displayport_enter(struct typec_altmode *alt, u32 *vdo)
{
	struct ucsi_dp *dp = typec_altmode_get_drvdata(alt);
	struct ucsi *ucsi = dp->con->ucsi;
	int svdm_version;
	u64 command;
	u8 cur = 0;
	int ret;

	if (!ucsi_con_mutex_lock(dp->con))
		return -ENOTCONN;

	if (!dp->override && dp->initialized) {
		const struct typec_altmode *p = typec_altmode_get_partner(alt);

		dev_warn(&p->dev,
			 "firmware doesn't support alternate mode overriding\n");
		ret = -EOPNOTSUPP;
		goto err_unlock;
	}

	command = UCSI_GET_CURRENT_CAM | UCSI_CONNECTOR_NUMBER(dp->con->num);
	ret = ucsi_send_command(ucsi, command, &cur, sizeof(cur));
	if (ret < 0) {
		if (ucsi->version > 0x0100)
			goto err_unlock;
	}

	if (cur != 0xff) {
		if (cur < UCSI_MAX_ALTMODES)
			ret = dp->con->port_altmode[cur] == alt ? 0 : -EBUSY;
		else
			ret = -EINVAL;

		goto err_unlock;
	}
...
```
- **Kconfig dependencies**:
  - `drivers/usb/typec/ucsi/Kconfig`:
    - `TYPEC_UCSI`: depends on `!CPU_BIG_ENDIAN`, `USB_ROLE_SWITCH || !USB_ROLE_SWITCH`.
    - `CONFIG_TYPEC_DP_ALTMODE` controls building `displayport.o` into `typec_ucsi` module.
    - Specific backend drivers: `UCSI_ACPI`, `UCSI_CCG`, `UCSI_STM32G0`, `UCSI_PMIC_GLINK`, `CROS_EC_UCSI`, `UCSI_LENOVO_YOGA_C630`, `UCSI_HUAWEI_GAOKUN`.

#### 4. Watch Out / Potential Loops
- Avoid repeatedly searching for callers of `ucsi_displayport_*`; caller hierarchy is already established (`ucsi_register_displayport` -> `ucsi_displayport_ops.enter` -> `typec_altmode_enter`).
- Next step: verify whether any mock/virtual PPM device or QEMU-reachable device exists for UCSI. If none exists and hardware/ACPI firmware is required, conclude reachability analysis under Section 2 ("Structurally unreachable hardware / execution paths").

							input: 47396
							output: 1993
							thoughts: 0
						

gemini-3.8-flash

null

null

							input: 21101
							output: 173
							thoughts: 171
						

**My Assessment of the `set-results` Function's Fuzzing Potential**

Okay, so I've looked at this `call:default_api:set-results` call, and the context is pretty clear. The `ucsi_displayport_enter` function has been modified, and it's part of the UCSI DisplayPort alternate mode driver. This immediately sets off alarm bells because UCSI drivers, like `ucsi_acpi`, `ucsi_ccg`, and the others, are fundamentally tied to *physical* hardware. We're talking ACPI PPM devices, ChromeOS ECs, or those external I2C Type-C controllers.

The kicker? We're fuzzing, and as we all know, standard virtualized environments like QEMU or GCE *don't* emulate this kind of hardware. There's no equivalent software layer or mock driver to stand in for the real thing. It's not like we can easily synthesize the environment. This means the modified code is essentially unreachable during our fuzzing attempts. This would be a complete waste of time. Therefore, `WorthFuzzing` has been correctly set to `false`.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The modified function `ucsi_displayport_enter` is part of the UCSI (USB Type-C Connector System Software Interface) DisplayPort alternate mode driver. UCSI drivers (such as ucsi_acpi, ucsi_ccg, cros_ec_ucsi, and ucsi_stm32g0) require physical platform hardware (such as physical ACPI PPM devices, ChromeOS EC, or external I2C Type-C controllers) that are not emulated in standard virtualized fuzzing environments (QEMU or GCE). Because there is no software emulation or mock driver for UCSI, the modified code is structurally unreachable during fuzzing.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The modified function `ucsi_displayport_enter` is part of the UCSI (USB Type-C Connector System Software Interface) DisplayPort alternate mode driver. UCSI drivers (such as ucsi_acpi, ucsi_ccg, cros_ec_ucsi, and ucsi_stm32g0) require physical platform hardware (such as physical ACPI PPM devices, ChromeOS EC, or external I2C Type-C controllers) that are not emulated in standard virtualized fuzzing environments (QEMU or GCE). Because there is no software emulation or mock driver for UCSI, the modified code is structurally unreachable during fuzzing.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null