[nekolyanich]

Replaces #296, which was opened on aurora-wip (since retired). Same change on integration/aurora, with the wake moved earlier, S0 restored when the driver is removed, and aurora's controller setup recovery taken into account.

On an M2 Pro (j416s), replugs of a USB-C to HDMI adapter in DP alt mode often never reach the display. On integration/aurora under the m1n1 hypervisor, 10 of 24 guided replugs were lost (6, 4 and 4 of 8 reached the display in three sessions), every other plug from some cycle on. Natively on our tree before this change, 26 of 56. A lost plug gets the Type-C partner, but nothing enumerates behind the adapter, the port gets no DP route and DCP no HPD.

Cause. After the unplug of a session with DP, the CD321x stays half-connected: a trace of its status showed the cable power path still "in" and the session's data status kept, and the next plug got no VBUS and never reached PD (2 of 2). Unplugging that plug clears the state, hence the alternation. macOS, traced on the same port with the same TV and adapter, puts the port into system power state 2 on every disconnect (0x2000 to the undocumented register 0x50, SSPS 2, 0x2000 and 0 to 0x50; 8 of 8) and sends SSPS 0 as soon as STATUS shows the next plug. At boot it also puts the empty MagSafe controller to sleep.

The change (CD321x only, port_sleep in tipd_cd321x_data; the driver tracks the port as unknown, awake or asleep):

• the cable work finds no plug on a port not known to be asleep (a disconnect, a retried one, an empty port at probe): the macOS sequence, after reading STATUS again; a plug present skips it;
• it sees a plug on a port not known to be awake: SSPS 0, before any teardown or partner registration;
• removing the driver: SSPS 0;
• a failure only warns and leaves the state unknown, as do resume and the controller setup recovery (which restores S0), so the next pass tries again.

Testing: MacBook Pro 16" M2 Pro (j416s), DCP firmware 13.5, a TV on the adapter, a Dell over Thunderbolt on another port, under the m1n1 hypervisor (with a bench-only DT change):

• integration/aurora without this change: 10 of 24 TV replugs lost, in three sessions;
• this commit: 8 of 8. An I2C trace of the controller shows the sleep sequence (state read back 2) at each of the 8 unplugs and SSPS 0 (state read back 0) at each of the 8 plugs;
• this commit, another session: unbinding the driver on the emptied port sends SSPS 0, binding it again puts the port to sleep at probe, then a plug and a replug about 1.4 s after an unplug both bring the TV back;
• no failed sleep or wake and no kernel warning in either session;
• earlier, as usb: typec: tipd: put an empty CD321x port to sleep, as macOS #296: on aurora-wip 4 of 16 replugs lost without it, 0 of 24 with it, 22 of 22 clean cold boots; natively on our tree 16 of 16 replugs, 3 of 3 fast replugs, MagSafe and Dell replugs back, a USB-C charger negotiated a contract.

Not tested:

• other Macs, SoCs, firmware, adapters and sinks; USB-only devices and docks;
• natively on integration/aurora; on it also MagSafe after its probe-time sleep, Dell replugs, resume, more than three cold boots, a replug within the 500 ms debounce;
• the controller setup recovery over a sleeping port (it needs a controller reset);
• shutdown and reboot: tipd has no shutdown path, so empty controllers may stay in state 2 while the Mac is off or boots another OS.

[RyanTheTide]

The current repair is review/pr425-fixtures-t3094-v3, head afe724c, with original authorship/sign-off followed by fixture-only commits. The original code reproduces 41/63 on this base; all 22 failures are fixture compile errors and the relevant production blob IDs are identical after repair. The repaired suite passes 66/66, keeping all 63 old groups and adding three actual power/ordering groups.

The fixtures retain distinct controller/fabric/external/mode/tunnel locks and unknown-key rejection. Three positive controls and six broken variants pass their expected outcomes; every mutant compiles and fails at runtime. This covers sleep with a plug, forgotten wake failure, cable wake/sleep and removal wake under a real mutex.

On integration/aurora at 421e314 with shared #438 and #456, DCP is PASS (66/66). KUnit has 905 passes and 1 policy skips. Universal WERROR is PASS; Fedora-base WERROR is PASS.

Software gates pass; hardware and shared #438/#456 review pending. The operator reports #456 passed all 63 host groups with stock make 3.81 and GNU Make; this worker did not rerun native macOS on the assembled base. Hardware still needed: J416s empty port/replug/resume/cold boot, MagSafe, USB-only and sleeping controller; M1 Pro/Neo regression.

[nekolyanich]

Tested on J416s (M2 Pro), review/pr425-fixtures-t3094-v3 (afe724c) plus a bench-only DT change (the HV's
atc0 kept out of the DCP routes), under the m1n1 hypervisor.

• KUnit, cd321x suites: 107/107.
• Cold boot, empty ports (3 boots): both empty USB-C ports read power state 02 at 18/18 reads; one sleep per port
  at probe (0x50=0x2000, SSPS 2, 0x50=0x2000, 0x50=0), no wake while empty.
• TV replugs, Dell in: 8/8 back; I2C trace shows SSPS 2 at each of the 8 unplugs and SSPS 0 at each of the 8 plugs.
• Unbind/bind of the TV port's controller, then a fast replug (~1 s out): the TV came back after both (1 session).
• Resume (pm_test=platform): TV alone, back by itself (1 resume). With the Dell too, the TV stayed dark until the
  first replug (1 resume). That is the base, not this PR: nothing was sent to the TV's port across the resume, and
  the same happens on the integration base without usb: typec: tipd: put an empty CD321x port to sleep, as macOS #425 whenever the Dell's tunnel gets -16 (12/12 resumes,
  8 boots); with thunderbolt: apple: let T6020 DP IN tunnels wait for a display pipeline #426's retry the TV is moved every time (14/14).
• MagSafe unplug/plug: 3/3, power state 02 out, 00 and the charger online back in.
• USB-only (USB 3 stick in the TV's port): 8/8 replugs enumerated, a sleep at each unplug and a wake at each plug.
• 0 tipd errors, 0 kernel warnings in all of these.
• Not run: natively; other partners (docks, chargers on the USB-C ports).

Runs and this summary were prepared with Claude (Opus 5.5); counts checked against the logs.