[erykwieliczko]

Integration currently can't build the M3 Air GPU runtime without the G15 (M3 Pro/Max) backend, which the Kconfig allows since 9dff537 ("drm/asahi: build the T8122 runtime without the G15 backend"). This PR makes that build compile again, and compile without warnings under W=1.

Each commit adds one #[cfg(CONFIG_DRM_ASAHI_G15)]:

1. Board::DeviceTree (g15/hw.rs). drm/asahi: g15: t6031: build the J516C board data without a board file #249 gave the variant a reference to super::board, which only exists with the G15 backend:

   error[E0433]: failed to resolve: could not find `board` in `super`
     --> drivers/gpu/drm/asahi/g15/hw.rs:54:32
   

   Fixes: aeffd0e53b42
   The commit also refreshes the whole-file hw.rs golden hash in tools/asahi/g15-zero-words-tests.py for that one line, with a note; the separately pinned T6030 module is unchanged.
2. Uat::try_bind (mmu.rs). Only G15 binds at publication. This is Scott's W=1 "never used" note from the G15: fix stamp wrap and VM slot exhaustion #233 review, which drm/asahi: carry G15 submission fixes and T6030 PMP votes with host coverage #253 didn't cover.
3. VmReadGuard::covers_range (mmu.rs). Only the G15 command checks use it (from Fix M3 Pro GPU bandwidth and G15 submission overhead #238, now in drm/asahi: carry G15 submission fixes and T6030 PMP votes with host coverage #253). Same W=1 warning.

No functional change: kernels with G15=y, including the published package, keep the same logic. The code isn't byte-identical: the added lines move later panic locations in mmu.rs.

W=1 build of drivers/gpu/drm/asahi (arm64, LLVM 18, Rust 1.85):

Config	integration 30a65186	this PR
M3_T8122=y, G15=n	does not compile (E0433 above)	compiles, no warnings
M3_T8122=y, G15=y	compiles	compiles; the same existing G15 dead-code warnings, none added

🤖 Generated with Claude Code

[maralcbr]

Thanks @erykwieliczko, the three gates are right and minimal. With G15=n the tree builds g15 from g15/adopt.rs, which pulls in hw.rs but not board, so g15/hw.rs:55 can't resolve. The variant is only built at g15/hw/t6031.rs:167 and matched in g15/initdata.rs:204,266,291, all G15-only. Uat::try_bind's only caller is g15/vm.rs:135, and VmReadGuard::covers_range is only used at g15/command.rs:410,412. The M3 and G17 callers go through Vm::covers_range (mmu.rs:1900), so nothing outside G15 loses a method. The Fixes: tag is right: aeffd0e landed after 9dff537 allowed G15=n.

One thing before merge:

• Please use Assisted-by: rather than Co-Authored-By:. CONTRIBUTING.md:80-81 points kernel patches at Documentation/process/submitting-patches.rst, which asks for an Assisted-by: trailer (submitting-patches.rst:638-643, with the format in the document it links). Please reword the trailer on all three commits. No code change is needed.

Worth knowing, not blocking:

• CI doesn't build the config this fixes. The compile job marks changed Rust as unchecked (tools/aurora-ci/compile-check.py:639-640, with --rust defaulting to skip), the package build uses G15=y (arch/arm64/configs/asahi.config:49), and the KUnit config has both G15 and M3_T8122 off. So your W=1 table is the only evidence for M3_T8122=y, G15=n, and that's fine for this PR. A follow-up that builds the Asahi Rust objects with that config would stop it breaking again. Passing --rust toolchain alone wouldn't be enough, since changed Rust files are still skipped at compile-check.py:639.
• Nit on the PR body: G15=y builds keep the same logic, but the code isn't byte-identical, because the added lines shift the panic locations later in mmu.rs.

The two host suites that read these files (tools/asahi/g15-queue-credit-tests.py and tools/asahi/g15-input-error-tests.py) pass locally. CI was still running when I looked. I'll approve once the trailers are updated and the package build is green.

[erykwieliczko]

Thanks. All three commits now use Assisted-by: Claude:claude-opus-5-5 (trailers only, tree unchanged), and I fixed the byte-identical claim in the description.

[scottjones]

We checked the three gates against their callers: all of them are G15-only, and the shipped G15=y kernel is unchanged, so this is a safe fix for the RC. We didn't build the G15=n configuration ourselves. A CI job for it, as Marcelo suggests, would stop this breaking again.

[maralcbr]

@erykwieliczko thanks. All three commits now carry Assisted-by:. The only other change since my review is in the first commit: the #[cfg(CONFIG_DRM_ASAHI_G15)] on Board::DeviceTree now comes with a refreshed golden hash for g15/hw.rs in tools/asahi/g15-zero-words-tests.py, and the docstring says why. The new hash matches hw.rs at this head (f29da6ef…). Kernel CI on f5d72333 passed, host suites and package build included.

Approving.