[7robertodantas]

Written with an AI assistant (Claude) on @7robertodantas's behalf; every hardware step was run and checked on the owner's J575c.

t6041-j575c: SuperSpeed for USB3 devices attached at boot

On the J575c (Mac Studio, M4 Max), a USB3 device that is already attached when the Mac boots enumerates at USB2. The SuperSpeed port stays at Link=RxDetect, although the T6040 PHY tunes the right lane and takes the PIPE. Replugging it in the same orientation gives SuperSpeed Plus. #1546 described this as orientation-dependent; it is not: on a fresh plug both orientations train Gen 2 (lane 0 and lane 1, same SSD and cable). Fixes #1670.

Cause. The four back ports have Type-C retimers (ADT i2c6/uatcrt0..3, Apple 0x05ac:0x2200). The AP does not configure them: macOS's only driver for them (AppleTypeCRetimer, 27.2.1 J575c kernel) reads the firmware version and NOR and collects crash logs, nothing about modes. The port controller (SN201202x) sets them up when a partner attaches. For a device attached before Linux, that happened long before the host PHY ran, and nothing redoes it.

macOS does not have the problem: with the same SSD attached across a reboot it runs at 10 Gb/s, and its boot log shows each port controller come up fresh as macOS starts ("AppLoaded, reinit", then "No plug detected", then "USB2 USB3 as DFP connected" about 250 ms later), so the device is attached again while USB comes up (Plug Event Count 2, ConnectionCount 1 on every port that had a partner).

The port controller's status, data status (0x71000080, USB2 + USB3), mode and register 0x5d read the same on Linux in the failing state as on macOS. One byte differs, byte 7 of register 0x7e:

Connection	0x7e byte 7
Linux, inherited from boot (SSD, USB2 hub, DP adapter)	0x04
Linux, after a replug (SSD at 10 Gb/s)	0x08
macOS, every connected port	0x08 (the DP adapter 0x49)
Linux, after this change, every renegotiated port	0x08 (the DP adapter 0x49)

Change.

1. dt-bindings: apple,reset-inherited-usb2-connection also covers this case (description only).
2. tipd: the J716c renegotiation (unlock, DISC with a delay, lock) gets a small board table. The J575c entry uses the key 575J (the reversed target identifier, as 617J for the J716c and as macvdmtool derives it), only renegotiates a connection without bit 3 in 0x7e byte 7, and leaves the port as it was if a step fails (it then only loses SuperSpeed) instead of failing the probe. The J716c path is unchanged.
3. sn201202x: prefer asynchronous probe, so the ports renegotiate at the same time (about 5.6 s each). The driver keeps no shared state besides the debugfs root, which is already locked.
4. J575c DT: the property on hpm1-3. hpm0 is left out: on this machine it carries the DebugUSB cable, so a USB3 device there was not tested (the driver skips a port in debug mode either way).

Tested on a J575c (linux-aurora 7.3.0, kernel 1943af8 with these driver changes as modules; DT = the live J575c tree plus only the property on hpm1-3, from a one-shot aura trial). Crucial X10 Pro (USB 3.2 Gen 2) on the fourth back port, a USB2 hub with the keyboard on the third, a USB-C DP adapter on the second, DebugUSB on the first:

	Before	Serial renegotiation	This PR
SSD attached across a reboot	USB2 480M, SS RxDetect (3 of 3 boots)	Gen 2x1, uas	Gen 2x1, uas, 926 MB/s (1 GiB direct read)
SSD attached across a cold boot (power off/on)	not tested	not tested	Gen 2x1, uas
Ports renegotiated by	-	25.1 s	13.8 s, all three within 2 ms
Keyboard hub, HDMI, USB-A (ASM3142)	working	working	working
USB-C DP adapter	working	hotplugs once at 16 s, then working	same
DebugUSB port	working	untouched	untouched
dt-validate (this tree's bindings)	no warnings	-	no warnings

Not tested: a USB3 device on the first back port (hpm0); USB4/Thunderbolt partners; s2idle resume with the change (renegotiation only runs at probe); other SN201202x boards (only the J575c and J716c entries act, and only with the property).

Notes:

• Don't let the AP talk to these retimers without a real driver: on a one-shot trial with i2c6 enabled, reading them over I2C (vendor/device ID, firmware string, registers 0x00-0x21) dropped an attached SuperSpeed device to USB2 5-8 s later and blanked a DP adapter on that port, until a replug. i2c-pasemi's SMBus block-read emulation also wedged that bus (it reads the length byte before it has arrived).
• The meaning of register 0x7e is undocumented; it is used only as a "this connection was attached with the OS running" check on the J575c.

🤖 Generated with Claude Code

[RyanTheTide]

@7robertodantas the dt-checks failure comes from this PR: the new apple,reset-inherited-usb2-connection description is a plain YAML scalar with "does not recover: a USB2 repeater ..." in it, and the ": " makes the schema fail to parse (dt-checks then reports every sn201202x node as unmatched). Using a block scalar (description: |) fixes it. The tipd changes look good; we will run the asynchronous probe on our sn201202x Macs once the binding is fixed.

[7robertodantas]

@RyanTheTide Thanks, fixed: the description is now a block scalar (description: |), folded into the binding commit. dt-doc-validate passes and t6041-j575c.dtb validates with no warnings. The tipd and DT commits are unchanged.

[RyanTheTide]

The binding parses now and dt-checks is green. The rest of the series is as reviewed. Because the asynchronous probe also applies to the sn201202x controllers on our M4 Pro and A18 Pro machines, it needs a few boots there before merge, to check port binding, the debug port, SuperSpeed enumeration and USB-C display before merging.

[DjDeveloperr]

Reviewed against current integration/aurora (I updated the branch so CI runs against it). The j575c DT edits don't overlap the recent HDMI, video-encoder or thermal changes, and the binding fix is right. The renegotiation is limited to the J716c and J575c by the new property plus the board table, and the J716c path is unchanged apart from its log line. The asynchronous probe looks safe for the other sn201202x machines. It has no shared state beyond the debugfs root, which already has a mutex. Deferral on the role switch still works, and suspend ordering follows device registration, so the registered-before-xHCI assumption holds. The one visible change is that /sys/class/typec/portN numbering may no longer follow DT order.

Optional follow-up: hold tps->lock across the renegotiation. The port is already registered, so a sysfs data/power-role change could otherwise send controller commands during the multi-second wait.

Approving. Following our current policy, the boots on the other sn201202x Macs that @RyanTheTide asked for will run after merge, with a revert ready.

The requested change (block-scalar description in apple,sn201202x.yaml) landed in f148531 and dt-checks is green, as RyanTheTide confirmed in his follow-up review. Under the maintainers' current policy, the remaining sn201202x boots run after merge, with a revert ready.