[erikwb]

On T6050 (M5 Pro and M5 Max), removing a PCI device behind an APIF DART and adding it back can hard-freeze the machine at that device's first DMA.

apple-dart-apif provides neither a release_domain nor a translation change in release_device(), which only frees the master. The IOMMU core requires one of the two. Without either, a removed device leaves its SIDs enabled on the domain the core frees next: domain_free doesn't touch the hardware for non-retained domains. When the same device comes back, its new domain is attached over that stale state.

This adds a blocking release_domain. Its attach takes the released device's SIDs out of the domain it's leaving, the same way attach_dev's unwind path does:

• disable the SID;
• undo the domain's mappings on it;
• clear it from the domain's stream map.

It takes the same locks in the same order as attach_dev. Retained SIDs keep their current handling.

Where it shows up

The N1 Wi-Fi/Bluetooth driver's firmware recovery removes the Wi-Fi and Bluetooth functions, resets the chip and rescans. Before this change, the first Wi-Fi DMA after the rescan froze the machine. That's about 250 ms after the Wi-Fi function's doorbell, once both IPC handshakes had already succeeded.

Testing (J716c, M5 Max)

This commit was run on the J716c daily kernel, together with the N1 recovery that removes and rescans the functions.

• Before: a forced recovery froze the machine every time and needed a forced power-off.
• After: 5 of 5 forced recoveries brought Wi-Fi and Bluetooth back in 9-10 s, with no DART errors.
• Normal boot is unchanged: device release only happens on removal.

Checks: checkpatch --strict is clean, and drivers/iommu/apple-dart-apif.o builds with W=1 and no warnings on this base.

Created with Claude Opus 5.5 in Claude Code.

[DjDeveloperr]

Approved on static review. The bare-metal M5 Pro uses the raw-MMIO apple-dart, not the APIF backend, so this path doesn't run on our rig.

Review:

• release_attach takes the prior domain's mutex, then streams_lock with IRQs off, then each DART's batch_lock, the same order as attach_dev.
• For each non-retained SID it disables the SID, undoes the domain's replayed mappings and clears the stream bit, as attach_dev's unwind does.
• Retained SIDs are left alone, and a failed DISABLE is logged without stopping the release.

Builds W=1-clean with APPLE_DART_APIF=y on a tree that merges this head. It also merges cleanly into current integration/aurora.

[DjDeveloperr]

Retested before merging on the M5 Pro (J714sAP, bare metal, SSD boot), kernel 7.3.0-m5-merge: the M5's integration kernel with this round's rebased heads in place of the old ones (every PR's own patch identical to what is merged; logs in work/m5-pr-merge-20261109). CI green.

Before merging, this round (these 14 PRs, #1323 and the rebased #1254/#1306/#938/#1316/#1199) was test-merged in order onto integration/aurora f9cf6f9 with no conflicts: apple-dt-check.sh 414 → 414 warning lines (0 new) over 137 DTBs, all 20 changed bindings pass, and a local host-test run fails only where integration itself fails with this host's newer toolchain. A full arm64 build of the same set on 8d98b7a was clean.

• Not on the bare-metal path (raw apple-dart, not APIF), so no hardware exercise; the DART-backed devices (DCP, GPU, ISP, PCIe/N1) all bind with no faults on the retest kernel. Builds in the full arm64 build of the merged train.

🤖 Generated with Claude Code

[DjDeveloperr]

Heads-up: shortly after this was merged, the owner asked for all APIF code (the old SPTM-support path: apple-dart-apif, apple-sart-apif, aurora-apif-mmio and the rest) to be removed from integration/aurora. A separate removal PR is doing that, and it deletes drivers/iommu/apple-dart-apif.c along with this change. Bare-metal T6050 uses the raw-MMIO apple-dart, which this doesn't touch.

🤖 Generated with Claude Code