[joske]

On a USB-C port that has run DisplayPort, the next USB 3 device can crash the PHY coprocessor. The port then stays at USB 2 until a reboot:

phy-apple-t6040-usb2 38aa90000.phy: USB3 PHY tuned: lane 1, coprocessor started, uc 0x881 -> 0xc81
phy-apple-t6040-usb2 38aa90000.phy: RTKit: co-processor has crashed
phy-apple-t6040-usb2 38aa90000.phy: RTKit: Message (id=1):  assert_id=1700
phy-apple-t6040-usb2 38aa90000.phy: USB3: the PHY coprocessor crashed

The next attach then fails as well (did not idle, phymxwrap suspend failed: -11, USB3 PHY bring-up failed (-11), USB2 only).

It happens every time a monitor is plugged in at boot and a USB 3 device then replaces it on the same port. If USB 3 has already run on the port that boot, it comes back fine after DP. So the coprocessor's first firmware boot crashes when it lands on the PHY state DP leaves behind. Neither plug orientation alone triggers it.

Four-lane DP holds the common block and the TX lanes on by override (t6040_dp_slpctrl), because nothing else powers them in that mode. But t6040_dp_power_off only cleared dp_up, so the PHY stayed awake in DP state. The USB 3 bring-up then woke an awake PHY and booted the firmware over it.

This releases the overrides and puts the PHY to sleep when four-lane DP ends, the same way the CIO teardown does (t6040_phy_tx_cmn_down + t6040_usb3_sleep). USB 3 then starts from a sleeping PHY, as on a fresh attach. Two cases are left alone: pin D, which keeps USB 3 running, and the fixed DP PHY of an HDMI converter.

Tested on an M4 Max J614c (left-front port, with #1476 and aurora-silicon/aura#147 for USB 3 on this machine):

• Monitor at boot, then the SSD: before, the coprocessor crashed every time and the port fell back to 480 Mbps. Now the log shows DP PHY down, PHY asleep, and the SSD (Samsung T7 Shield) comes up at 10 Gbps.
• DisplayPort and USB 3 alternated on the port several times in one boot. DP comes back with a picture each time, and USB 3 each time.
• Tested both as an out-of-tree module on linux-aurora 28.4 and built in with the 28.5 package.

Not tested on the M4 Pro, which shares this driver and the same DP path.

🤖 Generated with Claude Code

[DjDeveloperr]

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

Reviewed as the necessary1476 dependency. No blocking findings: the12-line teardown runs under the existing PHY lock only for active four-lane DP on a USB3-capable port, reusing the established TX/common-down and CFG-sleep sequence. PinD retains USB3 and fixed-DP HDMI are explicitly excluded. The J614c monitor-at-boot ->10Gb/s SSD and repeated DP/USB3 switching reports exercise the bug; host CI is green. M4 Pro regression remains a rollout follow-up.