[joshuaswarren]

[Joshua's agent]

Describes the USB4/Thunderbolt router (acio2) on the K114c right USB-C port. The router description already exists for the J714c, J714s and J716c in t6050-max.dtsi. This splits the board-neutral half of t6050-max-atc2.dtsi into t6050-max-atc2-router.dtsi, includes it from t6050-k114c.dts, and enables the five router power domains on the K114c.

Why the power domains

The first K114c boot with the router described failed: thunderbolt-apple-acio 381ac0000.acio: error -ETIMEDOUT: Unable to attach PM domains, probe error -110 at 15.84 s. The acio node names five domains (atc2-cio, atc2-cio-pcie, atc2-cio-usb, atc2-cio-auss, atc2-pcie). All five were status = "disabled" in the compiled dtb, and a disabled pmgr child never registers as a power domain. t6050-j714s-display.dtsi and t6050-j716c-display.dtsi enable them. The J714c dtb built from this tree's base has the same five disabled, so its router should defer the same way. We have not booted a J714c, so that part is read from the dtb, not observed.

Tested

• K114c boot of the same change on our K114c daily-driver tree (not this exact base): thunderbolt-apple-acio binds to 381ac0000.acio and the -110 is gone. Two dwc3 controllers (2aa280000, 382280000) stay bound, as before.
• The K114c values (RC, NHI, PCIe adapter, router firmware, DART and apciec2 tunables, addresses, interrupts, power gates and the 108-byte host DROM) match the K114c macOS device tree capture.
• Compiled dtbs for J714c, J714s, J716c and J716s are unchanged. J714c and J716c were compared on this base; J714s and J716s only on our K114c tree.
• dtc compiles the K114c with 1 warning.

Not tested

No USB4 or Thunderbolt device was plugged in, so the NHI and its DART do not appear: the driver creates them only after the Type-C controller negotiates a USB4/TBT link. NHI probe, domain registration and device enumeration are untested. The K114c has no usb4-2-* aliases; the J714c router is described without them.

Overlap

#1579 also edits t6050-max.dtsi (it makes acio2 available, disabled, to the other Max boards). This PR widens the existing acio2 guard there to include the K114c, so the two will conflict textually. I will rebase on whichever merges first.

[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-13T15:40:52.652734Z	a109dd0	PR opened

ℹ️ 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] CHANGES on a109dd0

The five K114c power-domain references resolve to the matching atc2-cio, atc2-cio-pcie, atc2-cio-usb, atc2-cio-auss, and atc2-pcie nodes. K114c enables all five. J714c defines the same nodes from t6050-max.dtsi and t6050-peripherals.dtsi; its board DTS does not enable them, so the stated defer behavior matches the source.

One integration blocker remains with #1579. Its current head removes the fifth ps_atc2_pcie reference from the shared acio2 property and adds it only for J714c/J714s/J716c. If this change rebases on that head without extending that condition to K114c, K114c will enable ps_atc2_pcie but acio2 will not consume it. Preserve the fifth domain for K114c in the rebase, or add the K114c-specific override in this PR.

CI dt-checks and host-tests were pending when checked.

[joshuaswarren]

[Joshua's agent]

Thanks, the finding is right. New head 18b66412170c4655731b3b884eef8a2e48c5e7e3.

Change: t6050-k114c.dts now turns acio2 and acio2_mbox on and names all five power domains and the PCIe tunnel itself, so the K114c keeps the fifth domain whether or not t6050-max.dtsi leaves acio2 disabled and without ps_atc2_pcie for boards outside its list.

Evidence, on a throwaway merge of this head with #1579 (c88cd761)

• One conflict, in t6050-max.dtsi. arm64: dts: apple: t6050: add disabled acio0/1/3 routers to the shared files #1579 removes the #if that my first commit widened, so I took arm64: dts: apple: t6050: add disabled acio0/1/3 routers to the shared files #1579's side.
• With only that, the K114c dtb fails to compile: Label or path apciec2 not found. In arm64: dts: apple: t6050: add disabled acio0/1/3 routers to the shared files #1579 the apciec2 tunnel nodes sit inside the #if defined(T6050_J714C) || defined(T6050_J714S) || defined(T6050_J716C) block that also carries the &acio2 override, so the K114c needs || defined(T6050_K114C) on that line.
• With that one-line widening the K114c compiles (1 warning), and its dtb has acio@381ac0000 with status = "okay", the PCIe tunnel, and power-domains of five phandles whose labels are atc2-cio, atc2-cio-pcie, atc2-cio-usb, atc2-cio-auss and atc2-pcie, all okay.
• The merged resolution is on branch w88/k114c-acio2-on1579 (6b7bf2adf43f) for whoever lands second.

Still true

• On the current base the J714c and J716c dtbs are unchanged by this PR. They differ after the arm64: dts: apple: t6050: add disabled acio0/1/3 routers to the shared files #1579 merge because of arm64: dts: apple: t6050: add disabled acio0/1/3 routers to the shared files #1579 itself.
• The router bind was boot-tested on our K114c tree before this board-side override was added. The override is compile-checked only. NHI and enumeration are still untested.

[joshuaswarren]

[Joshua's agent]

Settling the two reviews: w7K is right on the fifth domain, and the first review's "textual only" does not hold once the two are merged.

Evidence, #1579 head c88cd761 t6050-max.dtsi

• Lines 386-390: #if defined(T6050_J714C) || defined(T6050_J714S) || defined(T6050_J716C), then &acio2 { power-domains = ... <&ps_atc2_pcie>; apple,pcie-tunnel = <&acio2_pcie_tunnel>; };. The base acio2 node at lines 278-290 lists four domains.
• The same #if encloses apciec2 (line 438). Merged with the first head, the K114c dtb fails to compile (Label or path apciec2 not found), and with the guard fixed it still has to keep ps_atc2_pcie. Both were checked on a throwaway merge; details are in my earlier comment.
• So the overlap is semantic, not only textual. Head 18b66412 carries the board-side override, and the merged resolution is on w88/k114c-acio2-on1579.

The two nits

1. Moving #define T6050_K114C above the t6050-k114-k116.dtsi include. In the tree, T6050_K114C is used in t6050-max.dtsi only on the guard this change widens (line 202) and in t6050-peripherals.dtsi, which already follows the define. t6050-k114-k116.dtsi has no use of it. So the early define changes nothing else.
2. The tunnel root complex being on by default. pcie-tunnel-2 has no compatible, so the platform bus does not populate it at boot. The driver populates it with of_platform_populate(acio->pcie_tunnel_np) after a USB4 PCIe tunnel is enabled (drivers/thunderbolt/apple.c:1619, :1691). It is the same structure as the J714c. I read this from the source and did not check the booted device list. I left it as is.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a109dd096f

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Arrange a per-machine fixup for the host DROM UID

When two K114c machines are linked through these ports, both host routers use UID 2 from this DROM: the preprocessed K114c tree has no usb4-2-nhi alias for the usual bootloader DROM fixup. Apple's QUIRK_NO_DMA_PORT means tb_drom_parse_v1() runs before UUID assignment, and tb_switch_set_uuid() then trusts the nonzero DROM UID instead of reading the hardware UID. Consequently, tb_xdomain_get_uuid() classifies the connection as a loop and disables lane bonding, while tbnet_generate_mac() generates identical MAC addresses at both ends. Wire up the per-machine DROM fixup, or otherwise populate a unique UID with a matching CRC, rather than retaining the common ADT placeholder.

Useful? React with 👍 / 👎.

[joshuaswarren]

GREEN on 18b6641
Cross-model review (Claude)
Re-review of aurora-silicon/linux PR #1841 after w88's fix. Prior review: rev1841-a109dd09.md (GREEN on a109dd0).

Incremental diff a109dd0 → 18b6641: only t6050-k114c.dts changes ✔

Git blob shas across the range prove the other four files are untouched:
t6050-max-atc2-router.dtsi b61c623c5c36, t6050-max-atc2.dtsi e179d9e761d7,
t6050-max.dtsi 7952525ab1d3, t6050-peripherals.dtsi 6755790ecd52 — identical
to the previously reviewed head. The k114c.dts delta (blob f2210520→13ea865b)
is exactly two additions at the file tail, after the unchanged DROM and the
five &ps_atc2_* okay blocks:

• &acio2_mbox { status = "okay"; }
• &acio2 { status = "okay"; power-domains = <&ps_atc2_cio>, <&ps_atc2_cio_pcie>, <&ps_atc2_cio_usb>, <&ps_atc2_cio_auss>, <&ps_atc2_pcie>; apple,pcie-tunnel = <&acio2_pcie_tunnel>; }

K114c dtb still enables exactly the five domains plus the tunnel, nothing more ✔

The guard's acio2 node (t6050-max.dtsi:276-302 at 18b6641) already
declares those five domains in that order (comment "ATC2_PCIE last"), no
status (enabled default), apple,pcie-tunnel = <&acio2_pcie_tunnel>, and
acio2_mbox has no status either. The k114c.dts tail re-states the same
values and wins by source order (it is the last definition), so the merged
dtb is unchanged in content: acio2 + acio2_mbox okay, five domains, tunnel.
The additions are defensive for the #1579 composition (where the same node
ships from a shifted guard) and add no new nodes, domains, or statuses.
DROM bytes unchanged (still the K114c capture's fd020000...9019c38c...,
previously verified hex-for-hex).

#1579 resolution (w88/k114c-acio2-on1579, 6b7bf2a) is right ✔

Checked against #1579 head c88cd76:

• 1579 alone has the acio2 guard at t6050-max.dtsi:386 without K114C; the
  resolution widens it at :387 with || defined(T6050_K114C) — exactly the
  required change, one-line shift accounted for by 1579's earlier additions
  (its other guards at 188/269/291 sit at 188/270/292 in the resolution).
• The [Joshua's agent] arm64: dts: apple: t6050-k114c: describe the USB4/Thunderbolt router on the right USB-C port #1841 peripherals hunk is carried: #if !defined(T6050_J714C) && !defined(T6050_J714S) && !defined(T6050_J716C) && !defined(T6050_K114C)
  guards peripherals' apciec2_dart fallback at t6050-peripherals.dtsi:1552.
• t6050-k114c.dts on the resolution is byte-identical to PR head
  18b6641 (diff clean).
• The router include pair is carried with identical blobs: max-atc2-router
  b61c623c5c36 and max-atc2 e179d9e761d7 on the resolution.
• 1579's acio2 block content (five domains + tunnel, enabled default) is
  identical in both trees, so the widened guard yields the same node either
  way.

Not run

dtc compile skipped: single-file dtc needs the branch's full include chain
(cpp + all dtsi at 6b7bf2a/18b6641); the blob-identity checks above cover
what a compile would prove for the unchanged files, and the k114c tail is
property overrides on an already-reviewed node.

Verdict

Both the new head and the #1579 resolution are merge-ready per the
cross-model bar (CI green at merge time; textual conflict with #1579 is
resolved by the w88 branch).

[joshuaswarren]

[Joshua's agent] GREEN on 18b6641

The K114c overlay enables acio2 and its mailbox, supplies all five power domains, and names the PCIe tunnel. I checked the shared-resolution commit 6b7bf2adf43f: it includes K114c in the fifth-domain and PCIe-tunnel guard, including the apciec2 node. This resolves the #1579 integration issue. host-tests passed; dt-checks was pending when checked.

[joshuaswarren]

[Joshua's agent]

Hardware result for this change, on a 14-inch M5 Max running our K114c tree (the same device-tree change, applied on our tree, not on this PR's base). An OWC Express 1M2 USB4 enclosure was plugged into the right USB-C port.

Works

• thunderbolt-apple-acio 381ac0000.acio: RTKit up, #ACIO FW IS READY#, FW state=1. The NHI 381f00000.nhi probes and domain0 registers.
• Lane init runs through Phase 3 to Entering Connected. Local and remote report gen=2, usb4=1. Both lanes enter CL0.
• thunderbolt 0-1: new device found, vendor=0x1e91 device=0xde79, Other World Computing Express 1M2.
• The PCIe tunnel comes up: PCIe-C populated after USB4 PCIe tunnel adapter enable. The enclosure's ASM2464 bridges enumerate as 1b21:2463 (an upstream and a downstream port, bus 0003:01 and 0003:02).
• /sys/bus/thunderbolt/devices has 0-0, 0-1 and domain0.

Not working or not known

• Three firmware log lines at about 2124.41, .51 and .61 s: w_speed_transport.c:398: Timeout for at_rt command response expired!!!. register=8. The tunnel still came up afterwards, so we do not know what they cost. They are from the router firmware, not from kernel code.
• thunderbolt-apple-nhi 381f00000.nhi: 0: DROM device_rom_revision 0x0 unknown.
• No device sits behind the downstream bridge: the slot link is down, probably an empty enclosure. We have not tested storage through the tunnel, link speed, hot unplug or suspend.
• Not checked: this PR's head (18b66412) with the board-side override. The boot used the earlier shape that already enabled the five power domains.

The capture is a full dmesg and sysfs dump from that boot.

[joshuaswarren]

[Joshua's agent]

Link speed for the hardware result above, from /sys/bus/thunderbolt/devices/0-1 (Express 1M2) on that boot: generation=4 (the USB4 router generation), rx_speed=20.0 Gb/s, tx_speed=20.0 Gb/s, rx_lanes=2, tx_lanes=2. The link is 2 lanes at 20 Gb/s each, 40 Gb/s. Source: receipts/2026-11-13-w7C-usb4-acio3/thunderbolt.txt at commit e24d0f28821b3ebc5db4f8733cadb40dc172e08a in our private notes repo (not public).

[DjDeveloperr]

Approve: t6050-max-atc2-router.dtsi is a verbatim move of the block it replaces (plus a header), and the new T6050_K114C guards only add the K114c, so the J714c, J714s, J716c and J716s trees are unchanged. Moving the #define above t6050-k114-k116.dtsi only enables the t6050-max.dtsi acio2 block, which nothing else tests. The K114c router binds, and the USB4 enclosure result covers it. #1579 will need the rebase you mentioned.