[joshuaswarren]

[Joshua's agent]

Describes the two USB-C ports of the 14-inch M5 Max MacBook Pro (K114c) that Linux drives, so a USB device on them enumerates. Both ports carry USB only. Not described: the left-back port (ATC0), which is the boot and debug link; USB4 tunnels (ACIO); PCIe tunnelling; DisplayPort alt mode.

• Left-front port: ATC1, PD controller hpm1 on nub-spmi-a0 (SPMI address 0xa), ATC1 PHY and the dwc3 controller.
• Right port: ATC2, PD controller hpm2 on nub-spmi-a1 (address 0xc), ATC2 PHY and the dwc3 controller. nub-spmi-a1 deletes its interrupt property: the driver polls the PD controllers and refuses an interrupt on this bus, as on J714s. Without that the bus fails to probe with Generation 4 interrupt layout is not supported.
• MagSafe: the PD controller hpm5 (address 0x8) is described without a connector node and with apple,no-liquid-detection, as on J714s.
• nub-spmi-a0 gets its generation 4 fault queue window (ADT reg[1]) so spmi: apple: Drain the generation 4 fault queue #1713 can drain it, as on J714s.
• The shared t6050-k114-k116.dtsi keeps the ATC1 port disabled for K116; K114c enables it in t6050-k114c.dts only. This merges cleanly with arm64: dts: apple: t6050-k116s: N1, USB-C, SMC, DCP, sound, PMP/SEP, GPU, SD reader, microphones, camera #1648 (it only touches t6050-k114c.dts).

Test

• The DT builds with cpp + dtc.
• Booted on a 14-inch M5 Max MacBook Pro, kernel 7.3.0-k114c, with the left-front port: dwc3-apple started the xHCI host, a Realtek RTL8156 USB Ethernet adapter (0bda:8156) enumerated as SuperSpeed usb 2-1, r8152 bound (enu1: carrier on), /sys/class/typec/port0-partner appeared on controller 1-0a, DHCP gave an address and ssh over the adapter worked.
• Right port, same kernel: apple-spmi 28a1a8000.spmi probes, controller 2-0c registers /sys/class/typec/port1 with a partner (a USB-C power supply was attached: power role sink, tps6598x-source-psy-2-0c online) and no interrupt is registered for the bus (polled). A USB data device on the right port is not tested yet.
• Those boots used an older SPMI driver than spmi: apple: Drain the generation 4 fault queue #1713 and did not carry the MagSafe node, so the fault queue windows and hpm5 are not exercised by them.

Draft until a USB device is tested on the right port.

[joshuaswarren]

[Joshua's agent] w8B: result on a second kernel, and moving this out of draft.

Booted on the same 14-inch M5 Max MacBook Pro (K114c) with a newer kernel set (7.3.0-k114c, the one our integration build now defaults to), with this DT:

• All three Type-C controllers bind and register: 2-08 (the MagSafe PD controller, no partner, data role device, power sink), 0-0c (right port, ATC2: a partner is present, USB Power Delivery, power sink, a USB-C power supply is attached), 2-0a (left-front port, ATC1: partner present, data role host). A tps6598x-source-psy is registered for each.
• Left-front: dwc3-apple starts the xHCI host (2aa280000.usb, Configuration mismatch. dr_mode forced to host as before), and a Realtek RTL8156 USB Ethernet adapter enumerates as SuperSpeed usb 2-1, r8152 binds, the link is up (enu1).
• Right port: the bus is polled, no interrupt is registered for it, and the controller binds as before. Only dependency-cycle (fw_devlink) notices in the log.
• The typec port numbers are not stable between boots (the MagSafe controller registers a port, and the numbering moved between our two kernels), so tests should key on the controller names, as noted for J714s.

Not tested: a USB data device on the right port. The right port currently holds the power supply, so nothing has enumerated there yet; this is the one open item, and it needs someone to plug a device in. Marking ready for review now because the left-front port is verified on two kernels and the right-port description is the J714s one; if the right-port data test turns out to fail, I will follow up in this PR rather than leave it silent.

Not in this PR: the left-back port (ATC0, the boot and debug link), USB4 tunnels (ACIO, #1579 is the base), PCIe tunnelling and DisplayPort alt mode.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-12T22:25:56.372970Z	6fd895b	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[joshuaswarren]

[Joshua's agent] w8B: the right-port data test, which was the open item, is done and passes.

On the 14-inch M5 Max MacBook Pro (K114c), same kernel as the previous comment, the power supply was unplugged from the right port and a USB 3.0 flash drive plugged in:

• xhci-hcd xhci-hcd.1.auto (the right port's dwc3, 382280000.usb) registers: "Host supports USB 3.1 Enhanced SuperSpeed".
• usb 4-1: new SuperSpeed USB device number 2 (speed 5000), a PNY USB 3.0 flash drive; usb-storage binds, sda attaches (245235199 blocks, 117 GiB), partition table read.
• The Type-C controller 0-0c switches to data role host, power role source, with the drive as its partner (before, with the supply attached, it was device/sink).
• The drive mounted and read at about 137 MB/s with dd (reported by the person who ran the test, not measured by me).
• The left-front port still shows its USB Ethernet adapter on the other controller (2aa280000.usb, usb 2-1, SuperSpeed) at the same time, so both ports carry USB 3 concurrently.

So both described ports now have a USB 3 data device enumerating on this DT: left-front (two kernels) and right (one kernel, tested after the earlier comment). The right-port role swap to host works with the polled PD bus. Not tested: hot-plug of a device while the supply is attached (a supply-and-drive hub), and the intermittent hpm2 boot miss Dj described (#1713); this PR does not claim to fix it.

[RyanTheTide]

Endpoints and power domains check out against the J714s blocks, and both ports have a SuperSpeed device on hardware. Thanks for the right-port test.