[techmore]

On a T8132 port without the CIO calibration, serve the partner's USB2 when the port controller enters USB4 or Thunderbolt 3, instead of refusing the mux state. The J773g (Mac mini M4) is such a machine: its device tree has no apple,tunable-cio-* properties.

What the hardware runs below show is that the mux update now succeeds. In USB4, the port's xHCI then starts. In Thunderbolt 3 it also needs the companion tipd patch. They do not show a USB2 device enumerating during a USB4 or Thunderbolt link: the one dock I have showed nothing on D+/D- while in USB4.

Why. The J773g's SN201202x port controllers enter USB4 by themselves with a USB4 dock or another Mac, and Thunderbolt 3 alt mode with a Thunderbolt 3 dock. atcphy_typec_target_mode() maps those states to the USB4 and TBT PHY modes, and atcphy_mux_check() refuses both with -ENODEV when the CIO calibration is missing. The failed mux update makes cd321x_update_work() retry before it sets the USB role, so the port ends with failed to configure Type-C connection: -19 and cable revalidation failed after 3 attempts, and its dwc3 never starts an xHCI. USB 2.0 on D+/D- does not depend on the USB4 or Thunderbolt link.

The change. In atcphy_typec_target_mode(), on T8132 without CIO calibration, map USB4 and TBT to USB2. This works the same way as the existing fallback for DisplayPort pin assignments that the PHY cannot carry. The new fallback has to run before the DisplayPort fallback picks its usb_mode. That fallback compares its result with target_mode, so if it started from USB4 it would put USB4 back. Ports with the CIO calibration (the J713/J715 device trees carry it) are unchanged. A KUnit case covers both cases.

Tested on one J773g, natively, with kernels based on #1192 plus local J773g test commits, not on integration/aurora. In those kernels, the atcphy_typec_target_mode() change is behaviour-identical to this patch. They also had a TEST-ONLY log line for each mux request, which is dropped here. The patch on this base has not been booted.

• Run 53, without the change: a USB4 dock on Back Right and another Mac (USB4) on Back Left. On both ports the mux update failed with -19 three times, then cable revalidation failed after 3 attempts, and no rear xHCI came up.
• Run 54: a first version ran the new fallback after usb_mode was taken. The DisplayPort fallback put USB4 back and the ports failed with -19 as before. That is why the fallback now runs first.
• Run 55, this logic: the USB4 dock on Back Right got USB4/Thunderbolt is not available on this port: serving its USB2 only, the mux update returned 0 with the PHY in USB2, and the rear xHCI (41a280000.usb) registered. The dock enumerated nothing on that xHCI while it was in USB4. The Mac on Back Left (we are the UFP there, in USB4) took the same fallback and the mux update returned 0. A keyboard plugged into Back Right later enumerated on the rear xHCI.
• Run 56, same PHY code: the dock entered Thunderbolt 3 alt mode (SVID 0x8087), and the PHY served USB2 (state mode 2 alt 0x8087 -> PHY mode 1: 0). No rear xHCI came up because the port controller driver sets no USB role in TBT3. That is fixed separately in "usb: typec: tipd: Set a USB role for TBT3 on T8132 ports without a router". The Mac on Back Left: USB4 to USB2 again, mux 0.
• Run 57, same PHY code: the Mac on Back Left: USB4 to USB2, mux 0. The dock entered DP alt mode this time, so the fallback did not apply to it.
• The front USB keyboard enumerated in every run.

Runs 56 and 57 also had two TEST-ONLY sn201202x module parameters on the command line, which are not part of this PR. They change which mode the port controller picks for the dock (no USB4 host capability in the DFP VDO, Thunderbolt mode disabled). They do not touch the PHY.

Checks on this branch: scripts/checkpatch.pl --strict reports only the missing Signed-off-by (see below). arm64 W=1 build of drivers/phy/apple/ with GCC 15.2.0 / binutils 2.46, also with CONFIG_KUNIT=y and CONFIG_PHY_APPLE_ATC_KUNIT_TEST=y: no new warnings. The existing -Wparentheses in atc-j700-dp.h and the kernel-doc warnings on struct apple_atcphy are unrelated. I ran the phy-apple-atc-mux KUnit suite under UML (x86_64, CONFIG_COMPILE_TEST): the new atcphy_test_target_mode_t8132_cio and the other atcphy_test_target_mode* cases pass. Ten other cases fail the same way on the base, because UML's logic_iomem does not back their test registers. I did not run KUnit on arm64.

Not tested: this exact branch on hardware. Other T8132 boards. A TBT3 or USB4 dock that drives USB2 on D+/D- during the link (the one I have did not). J713/J715, where the path is unchanged.

No dependency: this applies to integration/aurora as is. The companion tipd PR, "usb: typec: tipd: Set a USB role for TBT3 on T8132 ports without a router", needs this one to have any effect on the J773g.

Signed-off-by from the author to follow. The commit is posted without one; I'll add mine before it's merged.

Written with help from an LLM; I reviewed it and ran the hardware tests above.