[ericjuta]

A USB-C hub with a DP output (Genesys 05e3:0610/0626 here) enters DP alt mode with nothing plugged in and takes the only T8122 external pipeline. A monitor on the other port then waits (… waits for a free external display pipeline) until the hub is unplugged, so it depends on which port came up first at boot.

When a port with HPD up finds no free pipeline, dcp_typec_reclaim_idle() frees one held by a direct DP-alt port whose sink never asserted HPD and that has no display connected. The idle port keeps DP mode and is routed again once a pipeline is free and its own sink asserts HPD. Nothing changes when the holder has a display, for tunnels, or for ports in SAFE.

Tested on J615 (with the J615 dcpext PR), hub on left-back, C49G95T on left-front:

allocated Type-C DPTX PHY 0
external display pipeline moves from USB-C Left-back (no display) to the display on USB-C Left-front
allocated Type-C DPTX PHY 1
dcp_hotplug() connected:1 valid_mode:0 nr_modes:32

Picture at 5120x1440@120, USB behind the hub kept working, 0 faults. Same path on J613 (one dcpext pipe); not tested there.

Disclosure: written with an AI coding agent (Claude); tested by me on the machine.

[ericjuta]

Combined-stack J615 hardware update: #356 (comment) . The user reports stable unplug/replug and lid-open/closed use on 7.2.11-dcpexp-usb-recovery-20261108, which carries this idle-port handover alongside display, thermal and USB-recovery changes. This supports the combined configuration but does not isolate this PR or constitute an exact-branch boot test.

[ericjuta]

Source-review follow-up on the combined stack: dcp_typec_reclaim_idle() currently returns false both when no idle route is found and when dcp_typec_route_deactivate(owner) fails. If no free route exists afterward, dcp_typec_route_set() returns the display-busy result. With the #163-style TIPD handling, -ENOSPC is treated as benign pipeline exhaustion rather than a retryable error. This can therefore lose a genuine teardown error during reclaim.

Before treating the combined recovery work as ready, I recommend preserving the deactivation errno separately from the no-idle-route result and adding a failure-injection regression. This is a source-derived concern, not a failure reproduced on the live machine; the reported successful lid/replug use does not exercise it. The local no-HPD routing and TIPD changes overlap #186 and #163, so I am not opening a duplicate PR.