Repository navigation
iommu/apple-dart: refuse v2.2 DARTs whose reg misses the exception records - #924
Merged
RyanTheTide merged 1 commit intoNov 5, 2026
Conversation
…cords T8110-family DARTs that report version 2.2 or later keep the exception bitmap at 0x4000 and the per-stream exception records at 0x8000 + 0x40 * sid. The reset path drains them on every probe. A node whose reg covers only the first 0x4000 bytes therefore faults on the first exception read. Device trees shaped after the Gravity M4 Mac mini (J773g) tree describe 12 DARTs this way (ADMAC, 8 USB, 3 PCIe). There the fault kills the kernel in the device initcalls and the bootloader watchdog resets the SoC about a minute later, with no output. Refuse such a node at probe with a message that names the region and the size it needs. Every DART this refuses already faults today, so no working DART changes behaviour. The consumers of a refused DART probe without an IOMMU once the deferred probe times out. The fix for the device tree is a reg of 0xc000 (the ADT gives 0x20000 for the PCIe DARTs). Tested on J773g with integration/aurora 19f71a1 plus this change: with the 0x4000 windows the kernel boots and refuses the 11 enabled short DARTs, and Ethernet, NVMe and ADMAC come up after the deferral; with 0xc000 windows no DART is refused. Fixes: f57d900 ("iommu/apple-dart: Support T8140 DARTs and firmware-owned stream roots") Assisted-by: LLM Signed-off-by: Sean Dolbec <sdolbec1@gmail.com>
Contributor
|
Merge train (MTL, 06/11). Gates passed on test tree 0412501 (integration/aurora 2661d71 + this batch):
|
satchlj
added a commit
that referenced
this pull request
Nov 5, 2026
Conflict in drivers/iommu/apple-dart.c, apple_dart_probe(): integration added the v2.2 reg size check (d6b6f2e, #924) right after the stream count check, where this branch adds the J613 live MTP bypass check. Keep both. The size check comes first: it only needs num_streams and validates the MMIO region before the J613 check reads a stream control register. Both checks fail the probe, so the order only decides which error a bad node reports. The J613 MTP DART node has a 0x4000 reg. T8122 DARTs report a version below 2.2: the other T8122 DARTs have the same reg size and are reset on J613 by kernels whose reset path reads the v2.2 exception records at 0x8000, without faulting. The size check therefore does not refuse the J613 MTP DART.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the Mac mini M4 (J773g, T8132), Aurora never booted with a GravityLinux-shaped device tree: no output, then a watchdog reset about a minute in.
Cause: T8110-family DARTs at version 2.2 or later keep the exception bitmap at
0x4000and the per-stream records at0x8000 + 0x40 * sid. The reset path drains them on every probe (apple_dart_hw_finish_reset()→apple_dart_drain_stale_exceptions()). Nothing checks that the node'sregcovers them. GravityLinux's J773g DT gives 12 DARTs (ADMAC, 8 USB, 3 PCIe) a0x4000window, so the first exception read faults in the device initcalls, the kernel dies beforeapple_wdttakes over, and U-Boot's 60 s watchdog resets the SoC.Change: at probe, refuse a v2.2 T8110 DART whose
regis shorter thanDART_T8110_ERR_SID(num_streams), with a message naming the region and the size it needs. The check runs afterversionandnum_streamsare read and before any access at0x4000or above. Tunneled DARTs:apple-dart.csetsversion0x0202 for the tunneled T8132 PCIe-C DARTs, so the check does apply to them; they pass becauset8132-usb4.dtsigives them a0x20000window. (Corrected 2026-11-05 after RyanTheTide's merge-train note.)Effect on other machines: none on a correct DT. Aurora's T8132, T8140, T8142 and T6040 DARTs are all
0xc000or0x20000, including every J713 node. Any DART this refuses already faults today, so it turns a silent crash into a logged refusal. The0x4000DARTs on M1/M2/M3 boot today, which means they report a version below 2.2 and are not affected.Trade-off: the consumers of a refused DART probe without an IOMMU once deferred probe times out, so they run untranslated. The alternative is a fallback that keeps translation on a short window using only the low registers (legacy
ERRORat0x100,DIAG_LOCK,BLOCK_ERROR, the TLB command). We built and booted two versions of that, but whether the legacyERRORregister latches faults on a v2.2 DART is not established, so this PR takes the smaller, safer change. The real fix is the DT (0xc000; the ADT gives0x20000for the PCIe DARTs); a matching fix for omacom/linux-aurora#332 is being pushed there.Tested on J773g,
integration/aurora@ 19f71a1 + this change (the hunk applies unchanged at 7d581f6), booted through m1n1-gravity → U-Boot → Limine:0x4000windows): boots to init at 1.7 s and logs 11 refusals (… too small for v2.2 exception records (need 0x8400); fix the DT reg) for the enabled short DARTs: ADMAC 390f00000, USB 402f00000/402f80000/40af00000/40af80000/412f00000/412f80000/41af00000/41af80000, PCIe 490000000/492000000. Ethernet (atlantic), NVMe and ADMAC come up after the deferral.0xc000: no refusals, Ethernet at 7.9 s; matches the unpatched kernel on that DT.0x4000DT never boots; with the windows enlarged, the unpatched kernel boots.--strictclean,W=1clean. Not tested on J713 (its DT windows are all large enough, so the check never fires there).Unrelated and unchanged by this PR: on J773g four locked DARTs (30a300000, 30a340000, 286340000, 48a340000) fail probe with
-EBUSYthrough a WARN iniommu_setup_default_domain().🤖 Generated with Claude Code