darp11-b: USB-C dock enters PD renegotiation loop

[amir-arad]

darp11-b: UCSI ACPI device not exposed; USB-C dock enters PD renegotiation loop

• Model: darp11-b
• BIOS version: 2025-04-03_04c4e20
• EC version: 2025-04-03_04c4e20
• OS: Ubuntu 24.04 LTS
• Kernel: 6.18.7-76061807-generic (System76)

Summary

On Darter Pro 11 (darp11-b, Intel Core Ultra 7 255H: Arrow Lake-H compute tile with the Meteor Lake-derived SoC tile, which hosts TB4/xHCI/USB-C PD), the firmware does not expose a UCSI ACPI device, so the OS has zero visibility into USB-C Power Delivery. Under load (battery < ~90%, dock + external display attached), the connector enters a PD renegotiation loop: both xHCI controllers reset their ports simultaneously, repeatedly, until the dock is physically unplugged. Symptom is reproducible with two different Dell USB-C monitors (P2723QE 90W, P2722HE 65W) and two different USB-C hubs. The same docks and monitors work correctly on other laptops.

The UCSI absence is unusual for a Thunderbolt 4 platform and I believe it is the root cause of the OS being unable to observe, recover from, or mitigate the PD loop. Kernel-side workarounds have only reduced frequency, not eliminated it. Because the affected silicon (SoC tile, TB4 controller) is Meteor Lake-derived and reused across both Core Ultra 1xx (Meteor Lake) and Core Ultra 2xx (Arrow Lake-H) parts, this may also affect the non--b darp11 and other System76 MTL-era machines.

System

Field	Value
Model	Darter Pro (darp11-b)
CPU	Intel Core Ultra 7 255H
Silicon codename	Arrow Lake-H compute tile + Meteor Lake SoC tile
FSP in use	MeteorLakeFspBinPkg (per models/darp11-b/ in this repo)
System76 firmware	v1.0.76
BIOS/EC version	2025-04-03_04c4e20
Kernel	6.18.7-76061807-generic (System76)
system76-dkms	v1.0.22
system76-power	v1.2.8
Distro	Ubuntu 24.04 LTS
fwupdmgr get-updates	"No updatable devices"

UCSI absence (verified)

$ find /sys/bus/acpi/devices/ -name "USBC*"
(empty)

$ find /sys/bus/platform/devices/ -name "*ucsi*"
(empty)

$ ls /sys/class/typec/
(empty)

$ strings /sys/firmware/acpi/tables/DSDT | grep -i ucsi
(empty)

typec_ucsi and ucsi_acpi modules load successfully but bind to nothing because no ACPI device is advertised. On other Thunderbolt 4 laptops I have access to, /sys/class/typec/ is populated with port entries and ucsi_acpi binds normally.

Expected on a TB4 machine: UCSI ACPI device (USBC000 or similar) -> ucsi_acpi binds -> /sys/class/typec/portN/ populated -> OS can read PD state and intervene.

Steps to reproduce

1. Boot with dock connected (Microchip USB5806-based hub, or generic USB3.2 hub; both reproduce).
2. Drain battery below ~90% (or use with a heavy workload).
3. Attach Dell P2723QE (90W USB-C PD) or P2722HE (65W USB-C PD) via dock.
4. Observe behavior over 2-5 minutes.

Barrel charger attached in parallel does not prevent recurrence. This rules out insufficient power budget.

Expected behavior

UCSI ACPI device is enumerated; /sys/class/typec/ populated with port entries; dock attaches once and stays connected under normal charging load.

Actual behavior

No UCSI ACPI device exposed in firmware; /sys/class/typec/ empty. Dock enters a connector-level PD renegotiation loop, cycling every ~8-9 seconds, and does not self-recover.

Observed PD loop signature

Most recent recurrence (2026-04-10): 110 USB disconnect events, 10 full cycles in 2.5 minutes, did not self-stabilize. Dock was physically unplugged to end it.

19:04:21  Dock connects (USB5806 hub + 11 peripherals enumerate)
19:04:29  FULL DISCONNECT #1  (all 11 devices, both controllers)
19:04:38  FULL DISCONNECT #2
19:04:46  FULL DISCONNECT #3
19:04:53  FULL DISCONNECT #4
19:04:59  FULL DISCONNECT #5
19:05:28  FULL DISCONNECT #6
19:05:41  FULL DISCONNECT #7
19:06:03  FULL DISCONNECT #8
19:06:26  FULL DISCONNECT #9
19:06:36  FULL DISCONNECT #10 (user physically unplugged)

Critical observation: the dock splits across two independent PCI devices:

Controller	PCI Address	Handles
Intel xHCI (0x777d)	00:14.0	Dock USB 2.0 hub, webcam, BT
Thunderbolt 4 xHCI	00:0d.0	Dock USB 3.0 hub
Thunderbolt 4 NHI	00:0d.2	USB4 host
TB4 PCIe root	00:07.0	Hotplug

Both controllers see their ports drop at the exact same millisecond on every cycle. A simultaneous drop across two separate PCI devices is not explainable by per-controller xHCI fault. It is the signature of a connector-level PD reset upstream of both controllers: the USB-C PD state machine in EC/firmware is dropping the link.

xHCI errors during earlier cycles

hub 2-1:1.0: hub_ext_port_status failed (err = -71)   # EPROTO
usb 2-1-port3: cannot reset (err = -110)              # ETIMEDOUT
usb 2-1-port3: attempt power cycle
xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state

These appear on the TB4 xHCI (00:0d.0). Transfer ring dequeue pointer desync on this controller is consistent with the host losing link state mid-transaction because the port was reset underneath it.

Triggers identified

• Spontaneous: no preceding suspend/resume, kernel goes straight to usb 3-6: USB disconnect. This is the dominant failure mode.
• Suspend/resume (S3): cascade immediately after resume; dock fails to cleanly re-enumerate.
• Boot-time: 2-3 cycles during the first ~2 minutes of uptime before stabilizing.

Power correlation (user-observed)

• Occurs when battery is significantly below ~90%.
• Does not occur when battery is near full.
• Both 90W and 65W monitors reproduce it.
• Barrel charger attached in parallel does not prevent it.

The 90W monitor provides the same wattage as the barrel charger, so this is not a power-budget problem. It appears to be the EC's PD logic failing under high simultaneous charge draw plus USB-C data, not insufficient supply.

Ruled out

• Cables (multiple tested)
• Monitor (two different Dell models)
• Dock hardware (two different docks, both work fine with other laptops on the same cables/monitors)
• USB autosuspend (pinned to on via udev on all dock hubs and both xHCI controllers)
• Thunderbolt runtime PM (disabled via udev: power/control=on on 00:07.0, 00:0d.0, 00:0d.2)
• LVFS firmware updates (none pending)

OS-side mitigations I already tried

Mitigation	Effect
Load typec_ucsi + ucsi_acpi at boot	Modules load, bind to nothing (no ACPI device)
Pin dock hubs to power/control=on	Reduced frequency, not eliminated
Pin TB controllers to power/control=on	Reduced frequency, not eliminated

These kernel workarounds delayed recurrence by 11 days but did not prevent it. Because the PD renegotiation is firmware-managed and the OS has no UCSI visibility, there is no kernel-side intervention point.

What would help

1. Expose UCSI in the ACPI tables. This is the concrete, high-value ask. With a working UCSI interface, the kernel can observe PD state, log actual renegotiation events, and potentially recover. Without it, every debug session is blind. I believe this alone would give you (and me) the observability needed to diagnose the underlying PD behavior.
2. EC firmware PD stability fix. If the renegotiation loop is an EC state-machine bug, it needs a firmware-side fix. I can't narrow this down further without UCSI visibility.

I'm happy to:

• Run any diagnostic commands or boot with kernel parameters you suggest
• Capture traces (dmesg, journalctl, lsusb -t, lspci -vvv, acpidump, TB tbtools) on request
• Test firmware builds from this repo on my machine

Attachments

I have the following logs from the 2026-04-10 recurrence:

usb-c-system-info-2026-04-10.log
usb-c-ucsi-boot-log-2026-04-10.log
usb-c-relevant-events-2026-04-10.log
usb-c-disconnect-events-2026-04-10.log
usb-c-dock-crash-loop-2026-04-10.log

Related

• System76 support ticket #20340 (submitted 2026-04-10)

[amir-arad]

Followup: I read through system76/ec and system76/coreboot to see what's missing

Finding 1: the EC has a USB-PD driver that darp11/darp11-b don't enable.

system76/ec's src/drivers/usbpd/tps65987.c is enabled on oryp11, oryp12, serw13, bonw15, and bonw15-b via CONFIG_DRIVERS_USBPD_TPS65987 = y. darp11 and darp11-b don't enable it, even though darp11-b/include/board/gpio.h defines HAVE_PD_EN 1 and gpio.c has PD_EN = GPIO(D, 4) // renamed to PD_POWER_EN. The EC powers the PD chip on and never speaks to it.

Finding 2: coreboot MTL has TCSS plumbing but no UCSI. src/soc/intel/meteorlake/ has tcss.asl, tcss_dma.asl, tcss_pcierp.asl, tcss_xhci.asl, and the darp11 mainboard dsdt.asl already includes tcss.asl. But UCSI returns zero hits anywhere under src/soc/intel/ in the fork. The 9 older boards that expose UCSI all use a discrete-TB4-on-PCIe pattern that doesn't translate to integrated MTL TCSS.

Two questions:

1. Is the USB-PD chip on darp11-b a TPS65987 (or compatible 65993/65994)? If yes, I'll submit the one-line patch to enable the driver. (Note: per tech-docs.system76.com, darp11 and darp11-b have different Clevo barebones, V560TU vs V540TU, so the answer may differ per board.)
2. Is UCSI for the integrated MTL TCSS on the roadmap, or deliberately deferred?

[crawfxrd]

There's a "UCSI spec", but no UCSI ACPI device AFAIK.

This specification does not define the method to use (PCIe/ACPI/I2C/etc.) in order to interface with the PPM.
It is left to individual system manufacturers to determine what bus/protocol they use to expose the PPM.

"TCSS" (Type-C Subsystem) is generally what's used.

If you own a System76 using open firmware, you can request schematics for reference.

• docs/schematics.md

Searching isn't great with whatever Clevo uses to generate it, but it generally is searchable these days. (The main thing I've found is it inserts a space after W. So, e.g., for PWR you'd also need to search for PW R.)

PD support definitely needs work in our EC, no question. The main thing might be that dTBT models require EC interop, whereas iTBT models do direct communication between PMC and TBT?