Framework Laptop 13 (AMD): iPhone USB-C disconnects in ~1s — cannot complete "Trust This Computer" (UCSI -110)

Framework Laptop 13
,
1

Summary

On my Framework Laptop 13 (AMD Ryzen 7040 Series), connecting an iPhone over USB-C causes the device to disconnect within about one second. The “Trust This Computer?” dialog on the iPhone cannot be completed because the connection drops before I can confirm trust.

The same cable and iPhone work reliably on another computer. This appears to be a USB-C / driver / UCSI stability issue on this machine, not a bad cable or iOS setting alone.

Hardware

  • Laptop: Framework Laptop 13 (AMD Ryzen 7040 Series)
  • BIOS version: 03.18
  • Connection: Direct USB-C to iPhone (expansion card removed during tests)
  • iPhone: Apple Inc. iPhone (USB ID 05ac:12a8, bcdDevice 17.02)
  • iPhone serial (redacted): 00008140-XXXXXXXXXXXX

Software

  • OS: Fedora release 44 (Forty Four)
  • Kernel (running): 7.0.8-200.fc44.x86_64
  • Installed kernels: 7.0.4, 7.0.6, 7.0.8 (all fc44)
  • usbmuxd: 1.1.1^20240915git0b1b233-7.fc44
  • libimobiledevice: 1.3.0^20240916gited9703d-7.fc44
  • Power profile: balanced
  • TLP: not installed; tuned daemon inactive

Steps to reproduce

  1. Boot Fedora 44 on Framework Laptop 13 (AMD).
  2. Connect iPhone with known-good USB-C cable (works on another PC).
  3. Unlock iPhone; “Trust This Computer?” may appear briefly.
  4. Within ~1 second, USB disconnects; device reconnects with a new USB device number.
  5. Repeat indefinitely; trust/pairing never completes.

Expected behavior

USB connection remains stable for at least 10–15 seconds so the user can tap “Trust” and usbmuxd can create /var/lib/lockdown/<serial>.plist.

Actual behavior

  • Repeated connect/disconnect loop on usb 5-1 (xhci_hcd).
  • ipheth attaches, then disconnect follows immediately (~0.5–1 s).
  • usbmuxd sees device briefly, fails to read lockdown plist, then device is removed.
  • GNOME shows repeated connection failure notifications.
  • Device reported as untrusted / not paired on Linux (symptom, not root cause).
  • lsusb often shows no Apple device because the link drops before enumeration completes.

lsusb (when briefly visible)

Bus 005 Device XX: ID 05ac:12a8 Apple, Inc. iPhone

Kernel log (journalctl -k -b, iPhone connected)

May 19 09:43:13 kernel: usb 5-1: New USB device found, idVendor=05ac, idProduct=12a8, bcdDevice=17.02
May 19 09:43:13 kernel: usb 5-1: Product: iPhone
May 19 09:43:13 kernel: ipheth 5-1:4.2: Apple iPhone USB Ethernet device attached
May 19 09:43:14 kernel: apple-mfi-fastcharge 5-1: USB disconnect, device number 29
May 19 09:43:17 kernel: usb 5-1: new high-speed USB device number 30 using xhci_hcd
May 19 09:43:17 kernel: apple-mfi-fastcharge 5-1: USB disconnect, device number 30
May 19 09:43:21 kernel: usb 5-1: new high-speed USB device number 31 using xhci_hcd
May 19 09:43:21 kernel: apple-mfi-fastcharge 5-1: USB disconnect, device number 31
May 19 09:43:24 kernel: usb 5-1: new high-speed USB device number 32 using xhci_hcd
May 19 09:43:25 kernel: apple-mfi-fastcharge 5-1: USB disconnect, device number 32
May 19 09:43:28 kernel: usb 5-1: new high-speed USB device number 33 using xhci_hcd
May 19 09:43:29 kernel: apple-mfi-fastcharge 5-1: USB disconnect, device number 33
May 19 09:44:35 kernel: ucsi_acpi USBC000:00: GET_CONNECTOR_STATUS failed (-110)

usbmuxd log

Connected to v2.0 device … serial 00008140-XXXXXXXXXXXX
ERROR: Failed to read ‘/var/lib/lockdown/00008140-XXXXXXXXXXXX.plist’: No such file or directory
Removed device 1 (~0.4s later)

What I already tried (no lasting improvement)

  • Different USB-C ports; direct cable without expansion card
  • Known-good cable; same phone + cable works on another PC
  • Module blacklists (tested, then removed): apple_mfi_fastcharge, ipheth, cdc_ncm / cdc_ether
  • Runtime: usbcore.autosuspend=-1
  • Kernel parameter (tested, reverted): amdgpu.runpm=0
  • iPhone: Reset Location & Privacy — cannot help while USB drops before trust completes

Impact

Cannot complete “Trust This Computer”; no USB file transfer or libimobiledevice pairing. Workaround: Wi-Fi only.

Happy to provide full journalctl -k -b export on request.

1 Like
2

it is know issues and if I good remember it affects other manufacturers with AMD board. One of the forum users was investigating the issue and by changing EC code or some settings using ectool he was able to mitigate the issue.
the only known workaround is using USB-A dongle to connect your phone.

FW 13/16 → usb-a → usb-a to usb-c adapter or usb-a to usb-c cable → phone

3

Agreed. The simplest workaround is to use a usb-a port on the FW13 and a usb-a to usb-c cable.

It is caused by a usb-pd negotionation bug. That protocol is only used on the CC pins of a usb-c connector.
Using usb-a connector uses a different protocol, and thus works. (It is a complete mystery why the usb-pd standard did not use the same protocol as usb-a did. Why need usb devices to now do two different protocols, when just re-using and enharnacing the old one would have been better)

I don’t have an iphone, but i have analysed similar connect on/off cycling problems. They are actually caused by the device not complying to the usb-pd standard correctly. FW implementation of usb-pd is standards compliant, but uses it in a way different from all other laptops, and thus it appears the FW is in the wrong here, when it is likely not.
If i was fixing FW compatibility problem, i would probably just copy what every other laptop does, and therefore be more compatible with non-compliant usb devices. In this case that would be using the 3A Rp resistor instead of the 1.5A Rp resistor.

4

Thanks — this matches my experience exactly.

On FW13 AMD (7040) + Fedora 44 + iPhone (05ac:12a8):

  • Native USB-C: connect/disconnect every ~1s, UCSI -110, cannot complete Trust.
  • USB-A expansion card + USB-A->USB-C cable: stable USB, no disconnect loop.

So the workaround works because PD on CC pins is bypassed. I’ll keep using USB-A for iPhone until FW/EC changes the Rp/PD behavior for better device compatibility.

Still working on lockdown pairing (idevicepair) over the stable USB-A path — separate from the PD issue.

5

This is a known issue as USB C is not compatible with iPhone 15 / Pro / Pro Max - #156 by Neekto