[dmitzsaz]

Newer ANS firmware moves the linear SQ doorbells (+0x24908/+0x24910) into the NVMMU block and ends the nvme register block at 0x10000. T6040 selects that layout by compatible (lsq_in_nvmmu).

T8142 can run either layout, depending on the ANS firmware of the macOS stub it boots. The J813 device tree describes a 0x30000 nvme block with the doorbells in it. A J704 booting the macOS 27.0 stub has them in the NVMMU, and its ADT gives the nvme block as 0x10000. With the compatible alone the driver writes the doorbells past the end of that mapping.

This takes the layout from the DT as well: if the nvme window doesn't reach the doorbells, they're in the NVMMU block and the firmware has already enabled them, as on T6040. DTs whose window covers the doorbells — including the current J813 one — behave as before.

Testing

• MacBook Pro 14" M5 (J704), macOS 27.0 stub: root filesystem on the internal SSD, in daily use.
• Builds on current integration/aurora (W=1; the only warnings are the existing -Wthread-safety-analysis ones on disable_lock, outside this change).
• Not tested on J813; its behaviour is unchanged by construction (its nvme window is 0x30000).

Prepares for the J704 device tree, which describes the nvme block as the ADT does.

Prepared with Claude Opus 5.5; tested by me on the hardware.

[RyanTheTide]

Tested before merging, silent: one-shot test kernel 7.3.0-aurora-f4mtr3x/y = integration/aurora 36d9198 plus this PR, #1082, #1083, #1084, #1060 and the Touch ID series, all merged onto the current tip. It was booted once on each of the four fleet Macs (M2 J413, M1 Pro J316s, J616s M4 Pro, MacBook Neo J700), and our regression suite was compared with the fleet30 rows on the same Macs:

• boot err-level lines and AVC: 0 on every Mac;
• 12 suspend/resume cycles with speaker regrant;
• Wi-Fi/BT reconnect, camera and display;
• AVD decode bit-exact (fps within ±2%);
• ANE runs and resumes.
  No regression came from these PRs.

For this PR in particular: built with 0 warnings. On all four Macs the nvme window reaches the linear doorbells, so lsq_in_nvmmu keeps its per-SoC value, and NVMe boot, suspend/resume and I/O behaved as on fleet30.

Thank you, Dmitriy!