Hardware / software
- Apple MacBook Air (M1, 2020) —
apple,j313 / apple,t8103
- Ubuntu Asahi (resolute), kernel
7.0.0-1002-asahi-arm (Ubuntu 7.0.0-1002.2, 7.0.2 base)
- Previous kernel
7.0.0-1001-asahi-arm (same 7.0.2 base) did not show the problem in ~2 weeks of use
Symptom
After some time running 7.0.0-1002 (machine s2idle-suspends daily), both USB-C ports silently stop sourcing power: plugging in a power-only sink (Samsung watch charging puck) does nothing. Meanwhile the sink direction keeps working — the laptop still charges from a USB-PD charger normally.
Because a wedged port never presents source capability on CC, a plugged-in sink produces no observable event at all: the shared CD321x IRQ (Apple-GPIO 106 in /proc/interrupts) does not increment, no typec partner is registered, nothing in dmesg. Two sinks facing each other = silence, which makes this easy to misdiagnose as dead hardware.
Additional stale-state evidence
One controller (2-0038) was also caught with stale state: its tps6598x-source-psy reported online=1 / usb_type [PD] (live i2c read through the driver) hours after the charger had been unplugged, while macsmc-ac showed offline and the battery was discharging. UPower also logged a spurious fully-charged event at the exact second of an s2idle resume, pointing at resume as the moment state goes bad.
Notably, direct register reads while wedged showed both chips still in APP mode with system power state S0 (reg 0x20 = 0x00), so this is not the known "CD321x left in low-power state" issue that cd321x_switch_power_state(S0) addresses — the chip claims S0 but no longer does source-role attach detection.
Workaround (confirmed)
Rebinding the tipd driver on both PD controllers fully restores port function without a reboot:
for dev in 2-0038 2-003f; do
echo $dev > /sys/bus/i2c/drivers/tps6598x/unbind
sleep 1
echo $dev > /sys/bus/i2c/drivers/tps6598x/bind
done
Immediately after rebinding, an already-plugged watch puck was detected: IRQ count incremented, port1-partner appeared, power_role flipped to [source], and the watch charged. I'm now running this from a /etc/systemd/system-sleep/ post hook as a stopgap.
Diagnostics captured while wedged
# watch puck physically plugged in, port dead:
/proc/interrupts: 100: 37 ... Apple-GPIO 106 Level 2-0038, 2-003f (static across plug/unplug)
/sys/class/typec/port*/power_role: source [sink] (both ports)
no /sys/class/typec/*-partner, no kernel log output on plug
# chip registers (i2ctransfer -f -y 2 w1@0x38 <reg> rN):
MODE (0x03): "APP "
PWR_STATE (0x20): 0x00 (S0)
STATUS (0x1a): 0x00 0x00 0x00 0x10 (no plug present — while sink physically attached)
Happy to provide more logs or test patches/kernels — the machine reproduces this within a day or two of normal suspend/resume use.
🤖 Diagnosed and generated with Claude Code
Hardware / software
apple,j313/apple,t81037.0.0-1002-asahi-arm(Ubuntu 7.0.0-1002.2, 7.0.2 base)7.0.0-1001-asahi-arm(same 7.0.2 base) did not show the problem in ~2 weeks of useSymptom
After some time running 7.0.0-1002 (machine s2idle-suspends daily), both USB-C ports silently stop sourcing power: plugging in a power-only sink (Samsung watch charging puck) does nothing. Meanwhile the sink direction keeps working — the laptop still charges from a USB-PD charger normally.
Because a wedged port never presents source capability on CC, a plugged-in sink produces no observable event at all: the shared CD321x IRQ (
Apple-GPIO 106in/proc/interrupts) does not increment, no typec partner is registered, nothing in dmesg. Two sinks facing each other = silence, which makes this easy to misdiagnose as dead hardware.Additional stale-state evidence
One controller (
2-0038) was also caught with stale state: itstps6598x-source-psyreportedonline=1/usb_type [PD](live i2c read through the driver) hours after the charger had been unplugged, whilemacsmc-acshowed offline and the battery was discharging. UPower also logged a spuriousfully-chargedevent at the exact second of an s2idle resume, pointing at resume as the moment state goes bad.Notably, direct register reads while wedged showed both chips still in
APPmode with system power state S0 (reg0x20=0x00), so this is not the known "CD321x left in low-power state" issue thatcd321x_switch_power_state(S0)addresses — the chip claims S0 but no longer does source-role attach detection.Workaround (confirmed)
Rebinding the tipd driver on both PD controllers fully restores port function without a reboot:
Immediately after rebinding, an already-plugged watch puck was detected: IRQ count incremented,
port1-partnerappeared,power_roleflipped to[source], and the watch charged. I'm now running this from a/etc/systemd/system-sleep/post hook as a stopgap.Diagnostics captured while wedged
Happy to provide more logs or test patches/kernels — the machine reproduces this within a day or two of normal suspend/resume use.
🤖 Diagnosed and generated with Claude Code