[DjDeveloperr]

After every sleep that keeps DRAM up, the T8140 error handler reported SoC NI 1 LINK_ERR PCIE_RXL ("ni1 source 19"); #1266 made it clear and log the latch. This stops the latch.

Cause: at the commit, the sleep controller clears the PCIe block's AXI enables (its link into the SoC fabric) between taking APCIE_SYS_GP off AUTO_ENABLE and lowering it, but only if the domain reads on at once. After a wake, the domain runs under AUTO_ENABLE. By the commit the hardware had idled it (0x1000030f), and it reads on again only about 0.3 ms after AUTO_ENABLE is cleared. So the enables were skipped, the block went down with its link set up, and NI 1 latched the error as ANS, the block's last domain, went off. The first sleep of a boot finds the enables clear as the loader left them, so it never showed there. macOS's own DRAM-kept sleep polls the word until it reads on, then lowers it.

Fix: wait for the domain to read on (bounded at 5 ms) before clearing the enables.

Hardware (MacBook Neo, J700, stock DTB, production command line, SEP active):

• Diagnostic kit, one boot: the latch first appears after the APCIe domains go off, before the engine runs. With the fix, 3 of 3 DRAM-kept sleeps read 0 at the commit and at the wake, with no report. Restoring the old check in the same boot latched 0x80 again.
• Final kit (this branch on T8140: USB-C PHY lock and NI error status after DRAM-kept wakes #1266, no test code): 5 sleeps, all returned. The first took the deep path and the other 4 kept DRAM. There was no NI report and the error-handler IRQs stayed at 0. After every wake: SSH, NVMe 64 MiB direct I/O, the USB hub and keyboard, Wi-Fi to the gateway and the panel were all fine. A hub replug re-enumerated. HPAI and LPAI recorded after sleeps 4 and 5.

🤖 Generated with Claude Code

[DjDeveloperr]

Superseded by #1445 (merged as 2b05915); its changes are in integration/aurora. The wait for the PCIe block's domain before its AXI enable is in drivers/soc/apple/sleep.c (renamed from t8140-sleep.c).