M1 Pro USB-C wedge: xHCI deregisters after SMC electrical fault; tps6598x unbind/bind hangs; typec identity sysfs oops

[duketopceo]

USB-C port wedge on M1 Pro: PD recovers, USB data path + DP alt-mode dead; tps6598x unbind/bind hangs

Machine: MacBookPro18,1 (M1 Pro), kernel 7.1.13.asahi3-1 (Arch ARM/Asahi pkg), Omarchy.

Summary

A USB-C hub (VIA Labs VL822 core, VL103 billboard, RTS5411 sub-hub, RTL8153 NIC) caused a cascade
that fully deregistered the port's xHCI controller. After the event:

• PD re-negotiates fine (45W contract, tps6598x-source-psy-* shows [C] PD)
• Type-C partner attach is detected but flaky (portN-partner appears, then vanishes)
• No USB device ever enumerates again on the affected port (root hubs present, tree empty)
• DP alt-mode negotiates (SVID 0xFF01, mode active=yes) but apple-dcp/mux never engages
• tps6598x unbind never returns (blocks forever in S state), rebind blocks too — sysfs driver-core writes hang
• Only a reboot recovers

Trigger

An electrical fault on the hub's SS path (-71 protocol errors repeated on 2-1.2-port4,
"Maybe the USB cable is bad?" spam, r8152 config reads fail) followed by SMC electrical events:

macsmc 290400000.smc: RTKit: syslog message: aceElec.cpp:1151:         Elec: Elec Cause 0x1000
macsmc 290400000.smc: RTKit: syslog message: aceElec.cpp:1151:         Elec: Elec Cause 0x200000
macsmc 290400000.smc: RTKit: syslog message: aceElec.cpp:1151:         Elec: Elec Cause 0x8020
macsmc 290400000.smc: RTKit: syslog message: charger.cpp:3203: Not charging:1000000

then:

xhci-hcd xhci-hcd.3.auto: remove, state 4
xhci-hcd xhci-hcd.3.auto: USB bus 2 deregistered
xhci-hcd xhci-hcd.3.auto: remove, state 4
xhci-hcd xhci-hcd.3.auto: USB bus 1 deregistered

Wedge repro (post-event)

1. Unbind: echo 0-003f > /sys/bus/i2c/drivers/tps6598x/unbind — succeeds (device leaves driver list)
2. Rebind: echo 0-003f > /sys/bus/i2c/drivers/tps6598x/bind — write hangs indefinitely (timeout 15 → rc=124)
3. Device sits driverless; PD stays up (charging continues); no attach/enumeration possible
4. Other ports' PD controllers (0-0038/0-003a/0-003b) still bound and working

The earlier full wedge (prior boot, same hub) showed:

phy-apple-atc f03000000.phy: Pipehandler lock not acked.
phy-apple-atc f03000000.phy: Failed to lock pipehandler

Second bug in same sessions (separate, patchable)

Reading typec identity sysfs from userspace oopses the reading task when identity data is
absent (both this boot and a prior one):

BUG: unable to handle page fault ... id_header_show+0x34/0x60 [typec]
pc : id_header_show+0x34/0x60 [typec] (P)

Repro: cat /sys/class/typec/port1-partner/identity/id_header on a freshly-attached
partner before identity resolves (segfaults the cat process, kernel oops logged).
cert_stat_show had the same signature on 2026-09-12.

Suspected mechanism

SMC electrical-fault handling tears down the ATCPHY/DCP path but leaves the TPS6598x
driver waiting on an event that can never complete, wedging i2c driver-core writes and
preventing re-probe of the port's phy/mux/dcp chain.

What we'd like

• Pointers to where the tps6598x bind can block (i2c reset path?)
• Any known interactions between the SMC Elec Cause handling and atcphy pipehandler locks
• If the typec identity oops is already fixed upstream, a pointer; otherwise we'll send a PR