[joske]

Fixes #1372. Two commits on top of #1345 and #1373:

• drm/asahi: admit the 25G83 image the 40-core J614C loads: adds this unit's loaded-image digest (sha256 7c04360e…ffec08a), which T6041 M4 Max: internal display on DCP through aura's handoff, and the 25G83 GPU build on 40 cores (#1332) #1345 expected.
• drm/asahi: leave +0x2610 at 0 for T6041 on 25G83: the actual fix.

The problem. With #1345, the J614C's 25G83 firmware boots, takes every job and marks its items done. But the GPU never runs one: no completion stamp, no fault, no firmware crash, and every job times out after 2 s. My comment on #1372 has the details.

The cause. One hardware-data word. The 40-core 25G83 configuration reuses the 25F84 profile, whose words include +0x2610 = 1. The J616C's 25G83 contents have 0 there, and so do #1373's 32-core builders, which reproduce those contents.

How I found it, on the J614C (one reboot per run):

1. AxxzyWasTaken's t6041-25g83-profile driver, the one the J616C ran 25G83 with, used with my J614C version of the capture: hangs.

2. The same driver with the J616C capture exactly as dumped (32-core words, 6-MCC map, the J616C's OPPs): runs.

3. A module parameter overlaid groups of my changes on top of (2):

   Overlay on the capture	Result
   core counts +0xf88, +0xfc0, +0x2570 = 40	runs
   +0xf6c, +0xf8c	runs
   +0xfac, +0xfb8	runs
   +0x2610 = 1 alone	hangs
   all of the above except +0x2610, plus this unit's OPP/CS tables	runs

4. On current integration/aurora (a82a1eb, with T6041 M4 Max: internal display on DCP through aura's handoff, and the 25G83 GPU build on 40 cores (#1332) #1345 and drm/asahi: add the T6041 25G83 profile captured on the J616C #1373), with the regular 40-core builders and the ADT-filled operating points:

   • as merged: hangs;
   • with +0x2610 left at 0: runs.

"Runs" means a Vulkan compute dispatch (1, 64 and 4096 workgroups), a buffer fill, a clear and a triangle render pass all complete with the expected contents.

The change. CONFIG_25G83 gets its own CHIP_25G83. That is CHIP with HW_DATA_WORDS minus its last entry, and a const match refuses to compile if that entry ever stops being (0x2610, 1, 1). The 25F84 configuration is unchanged, since astaff's J616C runs 25F84 with the word set. I don't know what +0x2610 controls.

Testing

• On the J614C (MacBook Pro 14" M4 Max, 40 cores, macOS 26.6.2 stub, iBoot mBoot-18000.161.10), with a linux-aurora package built from a82a1eb plus these two commits, booted normally (the GPU module autoloads and GDM starts on it):
  • the four Vulkan probes above pass;
  • vkcube runs;
  • Cinnamon and MATE on X11 (yserver) run on the GPU, with fractional scaling and full-screen YouTube;
  • GNOME on Wayland runs.
  • I haven't done long sessions, games or suspend yet.
• The negative control is this branch without the second commit: hangs exactly as before.
• tools/asahi/g17-t6041-initdata-tests.py passes. It now builds the 40-core 25G83 objects with CHIP_25G83, and checks that, apart from the register map, they differ from 25F84's only at +0x2610, where 25F84 has 1 and 25G83 has 0. The 32-core J616C hashes still match.
• tools/asahi/g17-firmware-selection-tests.py passes.
• The KUnit case t6041_builds_admit_only_their_own_images gains an assertion that the 40-core 25G83 chip has no +0x2610 word. I haven't run KUnit.
• rustfmt is clean on the changed hunks. The file's pre-existing import-order difference is left alone.

Known gap: the 25G83 render issues #1373 lists for the J616C (the 96-block render pool and four-cluster clustering metadata) may also apply here. Desktop use hasn't hit them so far.

🤖 Generated with Claude Code

[DjDeveloperr]

Reviewed both commits and the surrounding firmware selection and initialization paths. No blocking findings: admission still requires an exact normalized image identity; the new chip profile is selected only for the 40-core 25G83 configuration; 25F84 retains its existing hardware words; and the omitted +0x2610 word stays zero because initialization clears the object before applying overlays. The const split_last match guards against silently removing a different word.

Independently ran tools/asahi/g17-t6041-initdata-tests.py and tools/asahi/g17-firmware-selection-tests.py from exact head 49306bc; both passed, including unchanged J616C reference hashes. Changes since the branch point in integration/aurora do not touch these source/test paths. No GitHub checks or required branch rules are attached. I did not run a full kernel build, KUnit, or hardware tests; the reported hardware results remain the author's evidence. Known broader 25G83 rendering/long-session/suspend gaps remain outside this focused fix.