[chriskearney]

J514C/T6031 currently stops at the J516C-only G15 machine check and requires an explicit native-display enable flag. Admit the exact J514C + T6031 + DeviceTree combination on normal boots, with no kernel enable parameter. Default the exact J514C + T6031 native-display pair too, while preserving the explicit owner disable. Native display publication, DT/ADT shape, full board-scoped firmware identity, hardware identity/core masks, cold-start and record-builder checks remain required. T6034 and other boards do not inherit this path.

Paired normal-build Stage2 defaults: omacom/m1n1#23. Automatic SDDM ordering: omacom/omarchy-mac-pkgs#92. No J514C enable parameter or special Stage2 build flag is required by the final implementation.

The J514C firmware row pins the full canonical digest 669913fba2736e4b8f8a0f81eadc5ac00c9dc51fdd4c9d3770c66d2b0a1e8786, TEXT 0x64000, DATA 0x140000 and GKTS marker 0x5cf28 to apple,j514c. Existing J516C pins are now explicitly bound to that board. The table test discovers rows by binding and handles reordered or additional entries, including #340's proposed row.

The four inherited reference groups remain visible in the J514C warning: maximum power, relative-power curve, fast-die mask and alarm mask. They have not been independently measured in native macOS on J514C. OPP powers are boot-loader stand-ins and are not used to invent a chassis cap. Automatic startup does not establish sustained-load or power/thermal qualification.

Validation:

• Exact current head 837591a9081540cc6e8226b60ff931cc70272189 adds one diagnostic-only correction after 8c309ed2a18d: when PMP startup fails, the fallback message now names explicit apple_t6031_display.enable=0, because omitting enable=1 no longer disables the normal J514C/J516C display default. Checkpatch reports zero errors/warnings with sign-off checking disabled, and the production selector/owner-opt-out host checks pass. No hardware result is claimed for this new head; fresh CI is running.
• At 8c309ed2a18d82522d05528189d9958a6b7300a0, full arm64 Apple KUnit CI passed 146 suites/1,750 cases: 1,747 pass, three expected skips, zero failures/errors or kernel splats. All 51 display-gate cases pass, including default-on, explicit-disable and missing-marker paths for both J514C and J516C. Compile, boot, package, device trees, CI self-tests and all host groups also passed; human DCO alone blocked the aggregate result.
• At 8c309ed2a18d (including the native-display default correction): production GPU admission and native-display default selection pass for J514C without enable flags; the display test catches missing-board, missing-SoC and lost-opt-out mutants; wrong board/SoC/config and native-display failures refuse. Compiled admission/publication mutants are caught. The exact firmware suite passes 14 tests; reordered/extra-row cases pass and a missing J514C binding is rejected. These latest automatic-start changes have host evidence, without a new booted-kernel result yet.
• Historical hardware source b70a31fc134325b653ffa5ae8262a90902745402: ARM64 package build with LLVM18/Rust1.85 and zero resolved-config differences; installed kernel 7.2.11-14-1.5142-ARCH, package SHA256 794ce2eeba15abe5f3c9484562bf6ca555fefe0a6ed0831bff90e693cca8e906.
• On the full 40-core J514C, firmware reached READY with four ten-core clusters and native 3024×1964/120 Hz display. The installed job passed seven tests with identity MATCH before/booted/after and OMT NO_REGRESSION. A separate normal installed boot logged in automatically and passed native GLES3.2/Vulkan pixel checks on Apple M3 Max (G15C B2), 4,241/4,122 runs in three seconds, zero wrong pixels, actual archive-pinned providers, saved audio unchanged, stable monitor/Wi-Fi and no owned test processes left. That earlier build used the earlier admission gate; its result is not presented as a boot of this new head.
• OMT remains 31 pass / 4 fail / 38 skip: gpu.driver, gpu.vulkan, display.backlight, ports.external-displays remain recorded failures. Native pixel evidence does not turn those catalogue results into passes. Earlier unknown-firmware refusal and test-guard false-positive attempts remain in the evidence record.

The requested one-hour J514C native GL/Vulkan qualification remains held and its measurement interval has not started. A guarded attempt stopped after about 44 seconds when macsmc-ac/online read zero, following initial pixel checks and a ten-second ramp with no incorrect pixels. The observed maximum sensor temperature was 56.7 C, with no new GPU fault/recovery or thermal shutdown recorded. AC returned and 30 read-only samples stayed online/full/idle, but the CHIS transition and electrical-cause words remain unexplained. The adapter reported a 60 W input limit; GPU-only watts are unavailable and whole-system/SoC estimates establish no J514C chassis budget. This hold does not qualify sustained power or thermals.

The target keeps its previously tested installed package and original recovery artifacts. The local SDDM prototype worked there; the separately packaged wait still needs cold-boot qualification before release. This is short native correctness/login evidence, without CTS, benchmark parity, sustained-load/thermal or video qualification. No raw firmware bytes were extracted or published.

Human DCO certification is pending. The agent-added Signed-off-by trailers were removed under Documentation/process/coding-assistants.rst; explanatory commit bodies and Assisted-by attribution are present. The commit check remains blocked until a human reviews and signs the work. No merge or release is performed by this PR update.

[chriskearney]

Hardware result at b70a31f (J514C/T6031, kernel 7.2.11-14-1.5142-ARCH): the exact J514C firmware row matched, the cold-start/UAT checks passed, firmware reached READY, and all 40 cores were enabled. Native display started at 3024×1964/120 Hz.

The archive-pinned rendering checker passed with the installed Mesa providers actually mapped by the compositor and test processes: OpenGL ES3.2 reported Apple M3 Max (G15C B2), 4,112 runs in3 seconds; Vulkan reported the same GPU/device0x6031, 3,996 runs in3 seconds. Both had zero wrong pixels, no remaining owned test processes, stable monitor/Wi-Fi state and no recorded GPU/kernel faults. This is a short correctness smoke test, without CTS or performance/thermal qualification.

GUI assistance was required: the initial autologin session received SIGTERM at the framebuffer/VT handoff before the user's compositor started. One SDDM restart brought up the desktop; rendering then passed. An ordinary automatic login is therefore not qualified by this run. A target-specific readiness wait before SDDM is being checked separately with the installed packages.

OMT0.1.15 recorded30 pass/5 fail/38 skip, with0 regressions and display.controller/display.notch-strip fixed against the original baseline. Failures remain recorded: boot.kernel-package (the test kernel was staged rather than installed), gpu.driver/gpu.vulkan (reported unbound despite the direct native rendering evidence), display.backlight and ports.external-displays. These were not turned into passes by the rendering checker.

The normal job returned to the original kernel and Stage2. The original boot.bin was verified, and the owned guard/recovery copy removed. The candidate still uses the explicitly logged J516C reference power/thermal words; J514C power/thermal qualification remains open.

[chriskearney]

Addressed the initial review findings at aa285c8eee77f0b71d08eae6d525e1bbe54d84b0: both original kernel commits now have sign-off trailers, and the J514C firmware lookup suite is registered in the maintained CI manifest. The production driver/test source is byte-identical to the hardware-tested b70a31fc134325b653ffa5ae8262a90902745402; the only tree change is the ten-line CI manifest entry. The original tested commits remain available for the recorded package provenance.

Validation: the registered suite runs all 14 Rust tests successfully; all 148 CI self-tests pass locally; all three commits pass sign-off and checkpatch checks. An audit of all 119 tracked test-like files under the manifest discovery roots, including sparse-checkout paths, finds none unregistered. Fresh GitHub CI is running on this new head.

The paired Stage2 PR m1n1#23 now targets integration/aurora, reducing its diff to the intended three files (+40/-2), with the tested head 22bd9616205e3a7c795e47356a5fb80f8b4b2dec unchanged. Both PR descriptions now reflect the completed installed/normal-boot evidence and its power/thermal limits. No hardware rerun or installed-package change was needed for these review fixes.

[scottjones]

We reviewed aa285c8. The gate is correct and the J514C firmware row is properly scoped to the board. Our main concern is power: on J514C the borrowed J516C maximum power ends up as the only GPU power ceiling the driver configures. We'd like that bounded, or at least visible, before this merges. The firmware test will also break when #340 lands.

What we checked and are happy with

• The gate holds. j514c_candidate (g15/boot.rs:475) requires chip 0x6031, the DeviceTree platform, the parameter set to exactly 1, and both apple,j514c and apple,t6031. When the parameter is 0, J514C still stops at "not a T6031 G15C machine". J516C takes the same path as before, and T6034 and T6030 can't reach this code. The display, ADT, firmware identity, DMA-coherence and record checks after the gate are unchanged.
• The new firmware row (hw/t6031.rs:168-169) pins the full digest, both segment sizes and the marker, and is bound to apple,j514c through machine: Some(...). That matches the J514S row in #366.
• aa285c8 vs the hardware-tested b70a31f: git diff b70a31fc..aa285c8e touches only tools/aurora-ci/host-tests.json (the new suite entry). Driver and test sources are byte-identical. All three commits now have Signed-off-by. CI self-test, commits, compile, KUnit and all three host-test groups pass at this head.

1. On J514C the J516C maximum power is the only GPU power cap (main concern)

Reference::J516C.max_power_mw = 116739 (board/record.rs:229) goes into the power controller ceiling (+0x680/+0x6a4), the PPM block (+0x73c), the three zone-limit words (+0xe88..+0xe90) and the average-power controller (+0xfc4/+0xfc8).

On T6031 nothing else limits power. apple,power-zones is read with unwrap_or_default() (board.rs:60 and :131). m1n1 never writes that property: there's no power-zones anywhere in its src/. t6031-gpu.dtsi doesn't have it either. So J514C runs with zero power zones, and the 16-inch chassis's 116.7 W is both the ceiling and the average-power target.

The 14-inch has less thermal headroom. A higher ceiling borrowed from the bigger chassis is the unsafe direction. The relative-power curve and the two MTR masks are less worrying because they look like properties of the die, not the chassis. The hardware evidence is 3-second OpenGL ES and Vulkan pixel runs, which never exercise the power or thermal controllers. The PR itself says there is no sustained-load or thermal qualification. The firmware's own thermal sensors and the SMC are still there, so we expect throttling or a shutdown rather than damage. But this flag is meant for people to actually turn on.

Your ADT doesn't fill this in. Per the record.rs header, these four groups are "a word neither carries" (not the DT, not the ADT). The J516C values came from macOS's own driver on that machine. Concrete asks:

• Log the actual reference values in the J514C warning (boot.rs:512), together with the J514C's own top operating-point power from the m1n1-built OPP table. Then any boot log shows how far the borrowed ceiling sits above the board's own numbers.
• Before merge, if possible: for the candidate, cap max_power_mw at the J514C's top OPP power, or refuse if that power is above the reference. That makes the ceiling no higher than the board's own.
• Before J514C goes beyond opt-in: read the four groups from macOS on a J514C, the same way the J516C ones were obtained.

2. The firmware test hard-codes the row count, and conflicts with #340

tools/asahi/g15-j514c-firmware-tests.py:15 asserts len(rows)==3 and rows[2][2]=='apple,j514c', and existing_rows_unchanged loops 0..2. #340 adds a third J516C row at the same spot in t6031.rs. git merge-tree of the two heads gives a content conflict in hw/t6031.rs. When we resolved it by keeping both rows, this test failed with an AssertionError at line 15. Please find the J514C row by its machine binding rather than by index, and check every machine: None row instead of the first two.

3. With the flag set, J514C also accepts the unscoped J516C rows (minor)

The J516C rows at t6031.rs:142 and :154 (and #340's new one) are machine: None. Before this change only a J516C ever reached the identity check. With the flag set, a J514C whose TEXT matched one of those digests would pin as a "J516C" build. A digest match means identical bytes, so this isn't dangerous. Still, binding the J516C rows to apple,j516c, as #366 does for J514S, would make the "board-scoped" claim true for the whole table.

4. The commits have no body (minor)

All three commits are a subject plus Signed-off-by. The PR text won't be in git log. The commit should record where the J514C digest was measured (iBoot/OS versions, as #340 does), the hardware result, and that the J516C reference words are an unqualified assumption. The row name "runtime qualification pending" (t6031.rs:168) is also out of date now that the hardware run is posted.

What we ran (aarch64 host, Rust 1.85; CI uses 1.93.1)

• tools/asahi/g15-j514c-firmware-tests.py: 14 passed, including j514c_exact_candidate and existing_rows_unchanged.
• tools/asahi/g15-display-order-tests.py: passed (5 static checks, 7 C scenarios, 8 C mutants, 6 admit() mutants, including the 4 new candidate mutants).
• tools/testing/selftests/drivers/gpu/asahi-g15/run.py: 81 passed, 2 ignored (private fixtures). g15-maintained-handoff-tests.py --mutations: passed.
• Mutations of our own, each caught and then reverted:
  • j514c_bringup() changed from == 1 to != 0: the display-order test fails ("J514C requires exactly 1").
  • J514C row changed to machine: None: the firmware test fails.
  • Board check in admit() disabled: the display-order test fails.

What we couldn't verify

The hardware results. We only have the posted logs and didn't run anything on the machine. We didn't build the kernel or run KUnit locally (CI KUnit passes). We couldn't check the real J514C values for the four reference groups, or whether its ADT carries any power-zone data. We couldn't get an independent second review.

[scottjones]

Correction to our ask about capping at J514C's top operating-point power: on T6031 those OPP powers are m1n1 stand-ins (the G15S model, listed under asahi,t6031-gpu-standin), the same for J514C and J516C, so capping at or comparing against them doesn't tell us anything about the chassis. Please drop that ask. Logging the reference words is still useful, and the real fix is measuring J514C's own values in macOS.

For context, mainline Asahi gave the 14" and 16" M1/M2 Max the same chip-derived GPU power budget, so this may be lower risk than we framed it. The die-temperature controller and SMC also still apply.

One more: the PR body mentions a local SDDM readiness wait that was needed to avoid autologin racing the boot-framebuffer-to-native-DRM handoff. That isn't in any PR yet. Where should it land?

[chriskearney]

Applied the review follow-up at 0abb413b3ee78b29dbfcd959e4a829e781012f58.

• Kept the corrected power interpretation: the OPP powers are m1n1 stand-ins, so no cap or chassis comparison is derived from them. The J514C warning now logs all four groups from the actual selected Reference: maximum power, relative-power curve and both MTR masks. The inherited values remain explicitly unqualified.
• Found the J514C row by its machine binding, derived the row count, and checked every unscoped/J516C row. The 14-test suite passes on the production table, after reversing the rows, and with drm/asahi: g15: admit a third J516C GPU firmware TEXT (125f0497) #340’s proposed row inserted first. Both current J516C rows are now bound to apple,j516c; when combining drm/asahi: g15: admit a third J516C GPU firmware TEXT (125f0497) #340, its new row should retain that binding as well.
• Added explanatory commit bodies and assistance attribution, and updated the stale firmware label. The historical short hardware tests stay tied to b70a31fc1343; this revision has host evidence only and has not replaced the target package.
• The SDDM fix belongs in omarchy-mac-pkgs/omarchy-mac/lib/wait-for-display, which already owns the SDDM wait drop-in. It is now draft #92, with scoped readiness/timeout fixtures and manual/version updates. The packaged implementation needs cold-boot qualification before release. Two inherited systemd-261 Touch ID fixture failures reproduce on the unmodified base and are recorded there.

The production display/admission scenarios and mutants, maintained handoff suite, and all 148 CI self-tests pass. Checkpatch on the follow-up patch passes with sign-off checking disabled. I also corrected my earlier mistake: I had added Signed-off-by trailers as an agent, contrary to Documentation/process/coding-assistants.rst. Those trailers are removed; human DCO certification is still required. No power/thermal qualification, hardware rerun, release, or merge is claimed.

[scottjones]

We re-reviewed 7e4052e: the default-on commit f437596 and the comment update on top of 0abb413. Our earlier points are resolved, and the default-on change is clean. It just needs Chris's sign-off (see CI) and a couple of small tidy-ups.

Earlier points

1. Power: resolved. The J514C warning (g15/boot.rs:508-519) logs max_power_mw, the relative-power curve and both MTR masks from the selected Reference, marks them unqualified and says the OPP powers are stand-ins. These J516C values are still the known unqualified item on J514C. Before this merges, we'd like to see a sustained-load run on Ryan's Mac: about an hour of heavy GL/Vulkan load with GPU power, temperatures, clocks and faults logged, showing no faults, power at or under the budget and temperatures settling without an SMC shutdown. Measuring J514C's own reference values in macOS can follow later.
2. Firmware test and #340: resolved. It finds the J514C row by its binding and derives the row count. We merged #340's head (ce30ba3), kept both rows, and the test passed 14/14 with four rows.
3. J516C rows: resolved. Both are bound to apple,j516c (hw/t6031.rs:142, :154). #340's new row is still machine: None. Whichever PR merges second should bind it, or J514C would also accept that J516C firmware.
4. Commit messages: resolved.
5. SDDM wait: resolved. It's in omacom/omarchy-mac-pkgs#92.

The default-on commit

• Admission is still exact. j514c_board (boot.rs:475-478) needs chip 0x6031, the DeviceTree platform, and both apple,j514c and apple,t6031. T6034 has its own chip id and config, so the J514M, J516M and other boards can't reach it. Native display, the board-bound firmware digest, hardware identity and the record checks all still apply after it.
• The parameter is gone from asahi_core.rs and params.rs, and the harness now asserts it stays gone. Nothing in the tree reads it any more.
• Stale docs: 7e4052e fixed the module comment at hw/t6031.rs:3-6. The comment above machine: (t6031.rs:180-181) and the row name "(experimental bring-up)" (t6031.rs:168) still describe J514C as outside this config. Please update them to match.

Still open from last time, minor

• g15-j514c-firmware-tests.py:33 still uses any(...). A J516C row bound to the wrong board (we tried apple,j516m) still passes the test, even though a real J516C would then refuse its firmware. Use all(...) over the non-J514C rows.
• 0abb413 still carries Fixes: b70a31fc1343, the pre-rebase SHA of 4f45f48, which isn't in this branch. Please drop it or fold that fix into 4f45f48.

CI

Only ci / commits fails, and ci / result fails because of it. The cause is that none of the five commits has a Signed-off-by, and checkpatch's one error per commit is the same thing. coding-assistants.rst says agents must not add sign-offs, so this needs Chris's own DCO sign-off. Everything else passes: compile, KUnit, boot, device trees, package and all three host-test groups.

What we ran (aarch64 host, Rust 1.85; CI uses 1.93.1)

• g15-display-order-tests.py: passed (5 static checks, 7 C scenarios, 8 C mutants, 5 admit() mutants).
• g15-j514c-firmware-tests.py: 14 passed.
• g15-maintained-handoff-tests.py --mutations: passed.
• selftests/drivers/gpu/asahi-g15/run.py: 81 passed, 2 ignored.
• Mutations of admit(), each caught by the display-order test and then reverted:
  • the chip check widened to >= 0x6031 (lets T6034 in)
  • apple,j514m also accepted as the board
  • the board check ORed instead of ANDed
  • the reference warning dropped
• Mutations of the firmware table against the firmware test: J514C row unbound, or rebound to j516c, both caught. A J516C row rebound to j516m was not caught (see above).

[chriskearney]

The display-gate KUnit regression is fixed at 8c309ed2a18d82522d05528189d9958a6b7300a0, and the complete kernel CI run has now finished its technical checks.

The previous J514C normal-boot selector change removed gate_t6031_board, but the fixture still saved, restored and changed that variable. Simply deleting those references would also stop the default-path cases exercising the selector. The fix puts a KUnit-only static-stub point around the root compatibility query. Its replacement reads the current test's private context and uses KUnit's task-scoped resource cleanup; normal boot and other tasks retain the actual device-tree identity. The real J514C/J516C + T6031 selector and gate_run() remain active. Default-on, explicit enable=0, and missing-handoff-marker cases now run for both boards, checking the resolved request and the resulting node/PMP state.

Validation on this exact head:

• Full arm64 Apple KUnit CI: 146 suites, 1,750 cases; 1,747 pass, three expected skips, zero failures/errors and zero kernel splats. All 51 display-gate cases pass, including the six parameterized default/disable/missing-marker paths.
• A separate local arm64 QEMU boot also passed all 51 display-gate cases. The KUnit-enabled display-gate object compiled under LLVM 22. Checkpatch on this fix reports zero errors/warnings with sign-off checking disabled.
• Production selector tests cover 24 board/SoC pairs and catch missing-board, missing-SoC and lost-owner-opt-out mutations. The 14 firmware-admission tests and the display-order scenarios/mutations pass. Every J516C firmware row remains board-bound; an additional row from drm/asahi: g15: admit a third J516C GPU firmware TEXT (125f0497) #340 needs the same binding.
• Kernel CI run 42061154160 passes compile, boot, device trees, package, CI self-tests and all host-test groups. The commit-policy job remains red because human Signed-off-by certification is missing on the ten PR commits; the aggregate result follows that failure. No agent certification has been added.

The requested sustained J514C native GL/Vulkan qualification is still held. Its one-hour measurement interval has not started. The third guarded attempt stopped after about 44 seconds when macsmc-ac/online read zero, following the initial pixel checks and a ten-second ramp. The native GL and Vulkan rendering checks completed without incorrect pixels. The observed maximum sensor temperature was 56.7 C, with no new GPU fault, recovery or thermal-shutdown indication in the captured interval. The workload was drained and the accepted original boot/audio/desktop state was preserved.

The installed kernel maps AC online directly from SMC CHIS. Battery Full is a separate status, so reaching full charge does not by itself explain this transition; the CHIS observation also does not establish physical cable removal. The logged SMC electrical-cause words have no verified decoder here, so no specific electrical or thermal cause is assigned. AC subsequently returned online and 30 read-only samples over nearly 15 minutes stayed online/full/idle. That does not resolve the original stop or authorize a heavy-load retry.

The adapter reported a 60 W input limit. This installed driver provides no GPU-only watt reading; whole-system/AC-input power and the SoC heatpipe estimate are not substituted for one. No comparison against a 116.7 W reference or OPP stand-ins establishes a J514C chassis budget, and this short attempt provides no sustained thermal qualification. The macOS chassis measurements remain outstanding.

These hardware observations remain tied to the already-installed b70a31fc134325b653ffa5ae8262a90902745402 kernel source and 22bd9616 Stage2 cohort. Neither the latest normal-boot source changes nor this KUnit fix have been installed or cold-boot-qualified on that J514C by this follow-up. The SDDM readiness work remains separately tracked in omarchy-mac-pkgs#92. No release or merge readiness is claimed.

[scottjones]

We re-reviewed 837591a, which adds 8c309ed and 837591a on top of b424f38. There was no rebase, so this covers only those two commits. The KUnit fix is right, and the code is ready. What's left before merge is Chris's sign-off and the sustained-load run.

KUnit fix (8c309ed)

• gate_t6031_default_board() now asks gate_t6031_is_compatible() (t6030-display-gate.c:159-176). In a KUnit build, that function has a static-stub redirect, and the test file swaps in a stub that returns the current case's board (t6030-display-gate-test.c:388-396, :420). Normal boots and other tasks still read the real device tree.
• gate_t6031_default_board_on, _switched_off and _no_marker now run once each for J514C and J516C, through the real selector and gate_run(). They also check gate_t6031_requested. So _switched_off again shows end to end that apple_t6031_display.enable=0 wins on a default board, and now for both boards.
• CI KUnit at 837591a (run 42064643968) passes all 29 cases of apple-display-gate-t6031: 26 cases, with both params run on each of the three default-board cases. Overall: 1,750 run, 1,747 pass, 3 skipped.
• The new host test is registered, and CI self-test passes.

837591a

The diagnostic string only. apple_t6031_display.enable=0 matches how T6030 and T8122 describe their fallback.

CI at 837591a

The two failing checks are ci / commits and ci / result. commits fails because none of the 11 commits has a Signed-off-by. Checkpatch's one error per commit is the same missing trailer. result is the aggregate, and it fails only because commits failed. This needs Chris's own DCO sign-off, since coding-assistants.rst says agents must not add one. Everything else passes: compile, KUnit, boot, device trees, package, CI self-test and all three host-test groups.

Still open

• Sustained load: the one-hour run on Ryan's J514C hasn't been done. Chris's last comment says the measurement interval never started. The third attempt stopped after about 44 seconds, when macsmc-ac/online read 0. It also ran on the older b70a31f kernel and the 22bd9616 loader, not these heads. Now that the GPU and display are both on by default, we'd still like that run before merge.
• #340: its new J516C row is still machine: None at ce30ba3. The firmware test will fail when the two meet until that row is bound to apple,j516c.

What we ran (aarch64 host, Rust 1.89; CI uses 1.93.1)

• g15-j514c-display-default-tests.py: passed, with its 3 mutants caught.
• g15-j514c-firmware-tests.py: 14 passed.
• g15-display-order-tests.py: passed.
• Read the KUnit, commits and result logs of run 42064643968.
• We couldn't run KUnit locally (no qemu-system-aarch64 here), so the KUnit result is CI's.

[scottjones]

Hardware results from our Mac lab on a J514C (14" M3 Max, 40-core GPU), kernel built from 10a8340:

• Booted with no enable flags on the kernel command line (j1107-170124-f19e). This Mac still had asahi.g15_j514c_bringup=1 and apple_t6031_display.enable=1 from earlier bring-up, so we stripped them to check the default path.
• m1n1 stage2 v1.6.1-466-g6560adca. eDP-1 at 3024x1964 on apple-drm, asahi-g15 bound.
• Vulkan compute on "Apple M3 Max (G15C B2)": 860 dispatches, 0 bad of 26112 words checked.
• GL load for 5 minutes: 3524 draws, 0 bad. 0 DART faults. GUI smoke test passed.
• Earlier run with the flags still inherited (j1107-155356-f7a9): 20-minute GL load, 14065 draws, 0 bad, 0 DART faults. Hottest SoC die sensor peaked at about 102 °C.
• GPU tests used Mesa from asahi: admit the measured 30-core T6034 G15C contract mesa#32 (2c893e7abe), staged, not installed.
• Known: the kernel log notes the J514C power table is still an unqualified J516C reference ("OPP powers are boot-loader stand-ins").
• Seen once, not on the default-path run: an irq 81 apple_spmi_irq_handler bad_chained_irq warning on f7a9. It also showed up on a stock-kernel restore boot under the candidate m1n1 (j1107-162505-20ec), so it's probably not from this PR.

We also booted a combined trial kernel (#363 + #372 + #388 + #400, with m1n1 #23 + #24 + #25, stage2 v1.6.1-473-gd2b8d44b) on four other Macs: M3 Air and J504 Vulkan 780/0 bad each, J514M Hyprland at 3024x1964@120 with Vulkan 694/0 bad (mesa #32 staged), MacBook Neo wifi soak 9/9. 0 DART faults on all four, and no regressions vs stock apart from audio.microphone-signal on the J514M, which fails on its stock kernel too. This J514C hasn't run the combined kernel yet.