[AxxzyWasTaken]

Replaces #1050, rebased onto current integration/aurora as requested: the credit and authorship changes asked for in its review rewrite the commits.

Since #1050 was opened, integration/aurora gained #1345 ("drm/asahi: run the 25G83 build on the 40-core M4 Max"), which already has the per-build configuration that #1050 added. So this is now two commits on top of it:

• drm/asahi: add the T6041 25G83 profile captured on the J616C (7b7c237)
• tools/asahi: test the 32-core T6041 25G83 configuration on the host (226a65c)

What it does

The 32-core M4 Max in the J616C loads the T6041 25G83 image that #1345 admits, but that build runs the 40-core configuration, and its core check refuses this GPU. This PR lists the image a second time with a 32-core configuration (hw/t6041_25g83.rs). When several builds share an image, the selector takes the one whose configuration matches the probed clusters and enabled cores. If none matches, it takes the first one, so a 40-core part runs as before and any other layout is still refused. T6040 and T8140 are unchanged.

Changes from #1050

• The captured contents are gone: t6041_captured.rs and the code that applied it. The 32-core configuration now runs the 25G83 builders, like the 40-core one, using the operating points and the CS and AFR tables that the loader fills from the ADT (aura#68). Those tables are the values that vary per unit (binned voltages, one per cluster).
• Built on the host from this J616C's ADT values, the hardware data, power configuration and region C give the same hashes as the contents dumped on this unit on 25 Oct 2026. So the GPU gets exactly what it has run with.
• Some values stay static, because the driver has no source for them on T6041:
  • the selector ladders;
  • the 110586 mW power limit and the leakage coefficients, which are M4 Pro values, not measurements of this unit;
  • the AON rows, which come from the ADT ptd_data_table but are not published by the loader;
  • five power configuration words.
    The commit message says where each one comes from.
• Credits: the new file is GPL-2.0-only and carries Gravity Linux's copyright line. The commit has Niklas Sheth's Co-developed-by and Signed-off-by, copied from his commit 3a2ad76. Cody Ho is credited by name, with a link to his commit: the original encoder commit (bd25d19, cherry-picked from 778088823509) has no Signed-off-by to copy.
• Same as in drm/asahi: add the T6041 25G83 profile captured on the J616C #1050: 32 cores, operand banks for all 40 slots, four-cluster deflake, TA mode 1, a 96-block compute pool, and a six-MCC register map. A compile-time check now holds the map to T6041 M4 Max: internal display on DCP through aura's handoff, and the 25G83 GPU build on 40 cores (#1332) #1345's 25G83 layout rule.

Testing

• tools/asahi/run-host-tests.py --only g17: 30 of 30 pass.
  • g17-t6041-initdata-tests now builds the 32-core objects from the J616C's ADT operating points and checks the three hashes, and that the word at +0x9ec is -1000 / power limit.
  • g17-firmware-selection-tests compiles the real firmware_variant() and passes the new shared-image cases.
• The two const assertion blocks of hw/t6041_25g83.rs were compiled with rustc and hold. This used a one-off harness built from the initdata test, not committed.
• rustfmt --check is clean on the new file, and the changed hunks are stable under rustfmt. checkpatch.pl reports no errors, only the MAINTAINERS warning for a new file.
• Not compile-tested in a kernel tree: the build VM had no space for a Rust tree build. So the Gpu::new reordering, the CONFIG literal, hw/mod.rs, and the KUnit edits in fwid.rs and render.rs have not been compiled by the kernel build. KUnit was not run.
• Not booted. The J616C has run these contents on 25G83 only with the earlier 7.2 port.

Known gap, unchanged from #1050: on 7.2 this unit needed a 96-block render pool and clustering metadata sized for four clusters. Neither is in this PR.