Storage Expansion Card fails to enumerate on direct USB-C ports, works via dock (Framework 13 Pro, Panther Lake)

[ctl0v0]

Summary

The 1TB Storage Expansion Card is not detected when plugged directly into any of the laptop's USB-C ports, but works perfectly when connected through a USB-C dock attached to the same laptop. The direct port fails at the Type-C link-negotiation stage — the card never even enumerates as a USB device — and the port enters an infinite retry loop logging Cannot enable. Maybe the USB cable is bad? roughly every 4 seconds until the card is unplugged.

Hardware / Software

• Laptop: Framework Laptop 13 Pro (Intel Core Ultra Series 3), board FRANMJCP07
• BIOS/System Firmware: 03.02 (confirmed latest via fwupdmgr get-updates — no update available)
• USB4 Retimer firmware: latest (no update available via fwupdmgr)
• OS: Omarchy (dev c668141e, build 4.0.4), Arch-based
• Kernel: linux-omarchy 7.2.5-3 (Linux omarchy 7.2.5-3-omarchy #1 SMP PREEMPT_DYNAMIC Mon, 14 Sep 2026)
• Expansion card: Framework 1TB Storage Expansion Card — bridge chip enumerates as idVendor=13fe idProduct=6500, "USB DISK 3.2", SuperSpeed Plus Gen 2x1

Steps to Reproduce

1. Plug the 1TB Storage Expansion Card directly into any USB-C port on the laptop.
2. Observe: the card never appears in lsblk/lsusb; the kernel log shows the port failing to bring up the link at all.
3. Unplug and plug the same card into a USB-C dock, with the dock connected to the laptop via one of the same USB-C ports.
4. Observe: the card enumerates immediately and mounts correctly at full capacity.

Evidence

Reproduced identically on 3 of the 4 USB-C ports (usb2-port1, usb2-port2, usb2-port4) when connecting the card directly:

usb usb2-port4: config error
ucsi_acpi USBC000:00: unknown error 256
ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
[... repeats every ~4s indefinitely until unplugged ...]

Same sequence on usb2-port1 and usb2-port2, each on a fresh direct plug attempt.

At the point usb2-port1 began failing, the embedded controller also logged a buffer overflow, suggesting the EC itself is being flooded by repeated connector-status-change events during the failed negotiation:

cros-ec-dev cros-ec-dev.1.auto: Some logs may have been dropped...

By contrast, connecting the same card through a dock succeeded cleanly and immediately:

usb 2-2.1: new SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd
usb 2-2.1: New USB device found, idVendor=13fe, idProduct=6500, bcdDevice= 1.10
usb 2-2.1: Product: USB DISK 3.2
sd 1:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
sd 1:0:0:0: [sdc] Attached SCSI disk

Notes

• The GET_CABLE_PROPERTY failed (-5) / unknown error 256 messages also appear elsewhere in the boot log unrelated to this issue, and are a known cosmetic quirk (UCSI firmware not implementing that query) — I'm not claiming that message alone is the bug. The actual symptom is the port never completing Cannot enable, which does not happen at all when the same physical path goes through a dock.
• BIOS and USB4 retimer firmware are already at the latest available version per fwupdmgr, so this does not appear to be a pending firmware update.
• The 4th port was not yet tested with this card directly.
• Other USB-C devices (dock, video adapter, etc.) work normally in direct ports — this appears specific to this card, or to the power/negotiation profile it presents.

Happy to gather additional logs (omarchy debug --no-sudo --print, full journalctl -k around a fresh repro, fwupdmgr get-devices output) on request.