[rolotrealanis98]

Select firmware-27 method tables by exact compatibility build, record only observed 27.3 IDs, and refuse incomplete tables before starting the DCP. This revision does not enable native 27.3 display operation.

The two commits are rebased onto integration 12f3c1bf: the first carries Jeff’s build-selected 27.2 table from #894 with authorship retained; the second records the trace-supported 27.3 subset and adds safe admission. The untraced 27.3 swap serializer, enlarged request and scratch record have been removed.

Compat build	Populated entries	Missing required methods	Probe behavior
27.0.0	41	0	admitted; original table unchanged
27.2.0	40	0	admitted; optional dfb query omitted
27.3.0	20	21	refused before startup
unknown	none	n/a	refused

The 20 traced 27.3 entries include dfb_ready_query (A385); they are not 20 plus that query. The trace has no display client, so it does not establish mode-set, swap or power-state methods. Those other 21 entries remain absent. dfb_ready_query is the sole optional method, and its caller skips it when a table has no tag. Existing static H17P keeps its known entry. Each DCP and paired owner/peer uses its own selected table, initialized before RPC-capable setup.

Provenance and narrowing are documented by the author in comments 6766482670 and 6812012231. Further 27.3 enablement requires observed traffic for the missing methods and swap layout; no inferred replacement values are introduced here.

Validation of current head bf43e8cefdf39886e9b7e4ae68a8781533ac6633:

• Actual Host run 43137233102/job 130915374748 passed.
• Author reports both DRM subtrees compiled at the base and each commit with W=1/CLIPPY=1: 151 warnings each, none new. KUnit was enabled for compilation; suites were not run.
• Independent source review found no blocking defect in pointer initialization, per-device/paired dispatch, optional-query handling or missing-method admission. The 27.0 table is byte-identical to the base.
• A focused ASan/UBSan fixture executed the actual selector, tables, missing-method helper and probe branch. Exact unknown/missing compat refusal, 41/40/20 entries, 0/0/21 required gaps and optional-query behavior pass. Three controls compiled and failed their intended runtime assertions: unknown-build fallback, inverted missing-count gate and optional-query made mandatory. Property reads/logging are mocked; this is not physical startup or RPC transport qualification.

Current-head boot/refusal evidence received: author report 6823508816 boots the unmodified bf43e8cefdf3 image on J716s/firmware27.3 beta. With the same-build in-tree DT, userspace/network work but there is no DCP to probe. With the author's out-of-tree J716s DT describing DCP, probe reports21 missing methods (first dcpep_swap_start), no DCP RTKit/IOMFB startup follows, simpledrm retains card0 and userspace/network work. This satisfies the previously requested narrow refusal observation; native27.3 rendering remains unsupported.

Reset caveat: the author reports two earlier boots of the same image (one per DT) reset within about10s before logs were retained, followed by the two clean boots above. The cause is unknown and not attributed to this PR. Existing cmdline/trial-fallback/reset records, including whether arm64.nomte was set, would help characterize this separately. The report is not a uniformly clean boot series or general27.3 hardware qualification.

Final current-main source audit against c977dab3 merges cleanly and preserves all six feature added/removed line sets. The selected-method file and probe gate remain unchanged. Main adds an unnamed500 enum slot, but both its thunk and sleep RPCs explicitly exclude27.x; the focused actual-C gate fixture was rerun with the new enum and passed, including all three compiled runtime controls. No new kernel, KUnit or physical trial was performed by this review.

The old method/provenance finding and validation-only refusal gate are resolved. Further27.3 enablement still requires observed missing-method/swap-layout evidence; no guessed tags or removed serializer are restored.

[RyanTheTide]

1. Rebase onto the current head of funkzy/t6050-gpu-on-integration (0dd0833). That drops the 13 older base commits, which the branch now carries in rewritten form. Your two commits (96a21fd, 716bce0) replay onto it without conflicts.
2. The comment on dcp_methods_27_3 says the table was "Read from the 27.3 (26C5035) firmware's method dispatch". Method tags here have to come from observed traffic, such as a trace of the macOS driver's IOMFB calls on 27.3. Please confirm the 27.3 tags from a trace, say so in the comment and the commit message, and drop the reference to reading the firmware.
3. In dcp_methods_27_2, the comment says the dcpep_dfb_ready_query tag (A385) is "inferred, not yet observed". The same comment says an unknown tag makes the firmware panic. Please confirm the tag from a trace, or leave that method out of the 27.2 and 27.3 tables until it is observed.

[rolotrealanis98]

Updated (290b7de, 0cdf895).

1. Rebased onto the current head of funkzy/t6050-gpu-on-integration (65bb111).

2. 27.3 tags. I traced the calls the macOS 27.3 display driver makes to the DCP of the J716s while it starts (m1n1 hypervisor). The trace has 20 of the table's 41 methods, each with the request and reply sizes the driver uses. They include the three that differ from 27.2: set_display_refresh_properties A526, flush_supports_power A529 and register_dfb_surface A534. The table marks those 20 as traced, and the comment and commit message no longer refer to the firmware.

   That boot had no display client, so the trace has no mode set, swap or power state call. The other 21 tags are not confirmed by a trace. To be plain about where they come from: they and the 27.3 swap layout were first worked out by comparing the firmware builds. What the running system shows for them is that with this table and layout the driver starts the 27.3 DCP, sets its six modes and flips the panel on the J716s. I will take a trace with a display client and update the table from it. If you would rather hold the PR until then, or have the table cut to the traced tags, say so.

3. dfb_ready_query. The same trace has it at A385 on 27.3, right before set_display_refresh_properties, so it stays in the 27.3 table as traced. I have no 27.2 trace (the machine runs the 27.3 stub), so it is out of the 27.2 table. The driver sends an empty tag for a method without an entry, so boot_5() now skips the query when the build's table has none. That path is not tested on 27.2 firmware. It changes Jeff's commit; the [Rolando: ...] note in it says so.

Build: drivers/gpu/drm/asahi and drivers/gpu/drm/apple with W=1 and CLIPPY=1 at both commits; the warning set is the base's.

[RyanTheTide]

Thanks for the trace. Please cut dcp_methods_27_3 to the 20 traced methods plus dfb_ready_query and leave the other 21 out until a trace with a display client shows them (method tags worked out by comparing firmware builds can't go in this tree). With the base now in integration/aurora (#1012), please also check the PR builds and boots on the current integration/aurora head; CI did not run after the retarget, so a push will start it.

[DjDeveloperr]

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

The maintainer's latest request on this same head is still unmet: the 41-method 27.3 table must be cut to the20 observed/traced methods plus dfb_ready_query, with the other21 untraced entries left out. Then rebuild against current integration and boot that result. This is a source/provenance gate, not merely a missing merge. Please retain exact firmware admission and avoid allowing unobserved method IDs just because another session rendered.

[DjDeveloperr]

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

Formalizing the concrete source blocker in the preceding review: the current27.3 table still has41 methods while only20 plus dfb_ready_query are observed. The latest maintainer request on this head explicitly requires leaving the21 untraced entries out. Please provide the trace-supported narrowed table and safely gate any callers that require unavailable methods; do not silently send empty method tags or weaken exact firmware admission. Then rebuild/retest on current integration. CI or a website label cannot clear this unresolved method/provenance gate.

[rolotrealanis98]

Updated (61a1fd0, bf43e8c).

1. Rebased onto the current integration/aurora head (12f3c1b); both commits replayed without conflicts.
2. dcp_methods_27_3 is cut to the traced methods. That is 20 entries, not 21: dfb_ready_query (A385) is one of the 20 the trace shows, I counted it badly in my last comment. The other 21 have no entry.
3. The 27.3 swap layout is gone from this PR too (iomfb_v27_swap_wire(), the 0x1144-byte request and its scratch record). swap_submit is one of the untraced methods, and the layout had the same origin as the 21 tags. It comes back with a trace that has a swap.
4. Callers. The driver sends every method of the 27.0 table, so instead of gating them one by one, probe now checks the table of the build: if it lacks the ID of any method the driver sends, the firmware is refused with a message naming the build, the number of missing methods and the first one. dfb_ready_query is the one exception, since boot_5() already skips it for a build without one. The 27.0 and 27.2 tables pass. "27.3.0" selects its own table and is refused by this check, so no empty tag can go out, and firmware admission is as exact as before.

The result is that this PR no longer starts a 27.3 DCP: it records the traced IDs and the selection by build, and the panel stays off on 27.3 until a trace with a display client fills the rest. The title says so now; the description above still describes the first revision.

Build: drivers/gpu/drm/asahi and drivers/gpu/drm/apple with W=1 and CLIPPY=1 at the base and at both commits, 151 warnings each, none new; compiled with CONFIG_KUNIT=y, suites not run. Not booted: on the J716s (27.3) the expected result is the refusal message at probe, and I have not run it yet.

[DjDeveloperr]

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

The previous source/provenance finding is resolved. The revised 27.3 table contains 20 observed entries including dfb_ready_query, leaves the other 21 absent and removes the untraced swap layout. Independent source review confirms that completeness rejection precedes allocation/DMA/PHY/RTKit startup; selected tables are initialized before callers, paired submissions use the right owner/peer, and the sole optional-query caller is guarded. The 27.0 table is byte-identical to the base, while the 27.2 table omits only that optional query. No new blocking source defect found.

I exercised the actual public tables/selector/missing helper and actual probe branch under ASan/UBSan: exact unknown/missing compat refusal and the 41/40/20-entry, 0/0/21-required-gap behavior pass. Unknown-build fallback, inverted missing-count admission and mandatory optional-query controls all compile and fail at runtime. Mock property/logging boundaries do not prove a physical boot or RPC transport. Current Host job130915374748 passed; your reported current-base/per-commit subtree builds close the earlier stale-build item at their stated scope. I corrected the obsolete description and preserved its original text in local review evidence.

The remaining requested item is the existing current-head boot/refusal report, which your update explicitly says is unrun. On this narrowed source, the expected 27.3 result is refusal before DCP startup; native 27.3 rendering or refilling untraced IDs is not required for that report. Earlier boots with the removed full table/wire layout do not substitute. Keep this unmerged until that result is available; do not guess IDs, restore the removed serializer or launch new machine work from this thread.

[rolotrealanis98]

Boot report for the current head bf43e8cefdf3 on the J716s (MacBook Pro 16-inch, M5 Pro), firmware 27.3 beta.

Kernel: built from the unmodified head (defconfig + asahi.config + my J716s fragment, DRM_APPLE=y), release 7.3.0-pr1174-bf43e8cefdf3.

1. With the in-tree t6050-j716s.dtb from the same build: boots to userspace and network. There is no apple-dcp line, because the in-tree J716s tree does not describe the internal display engine yet (only J714s includes the panel dtsi), so the driver has nothing to probe.

2. Same image with my out-of-tree J716s device tree that describes dcp (the loader hands it over):

   [    0.122132] simple-framebuffer 10bd15f4000.framebuffer: [drm] fb0: simpledrmdrmfb frame buffer device
   [    0.122630] apple-dcp 48ae00000.dcp: DCP firmware-compat 27.3.0 not started: no ID known for 21 methods (first: dcpep_swap_start)
   

   That is the only apple-dcp line in the log: no RTKit start for the DCP and no IOMFB traffic follow it. simpledrm keeps the framebuffer (card0), and the machine reaches userspace and network.

One thing I could not explain: my first two boots of this image (one with each device tree) reset within about 10 s and the machine fell back to its daily kernel before any log was kept. The two boots after that, same image, were clean and are the ones reported above. I do not know the cause and have no evidence it is related to this PR.

No IDs were added and nothing else changed on the branch.

[DjDeveloperr]

Report6823508816 fulfills review5867881665's remaining narrow current-head boot/refusal gate. The same-build stock DT boot reaches userspace/network but does not exercise DCP. The author's DCP-describing DT with the unmodifiedbf43 image exercises the intended branch:27.3 reports21 missing methods, no DCP RTKit/IOMFB startup follows, simpledrm retains the framebuffer and userspace/network survive. Native27.3 rendering is not required or enabled by this narrowed PR.

The two earlier unlogged ~10s resets are retained as an unresolved, unattributed reliability observation; I am not calling all four boots clean or diagnosing MTE. If retained, please post the existing cmdline (including arm64.nomte status), trial/fallback metadata and any reset/baseline records. This is not a request for another hardware run and does not change the accepted scope of the two reported boots.

Source review remains clear. Current Host43137233102/job130915374748 passed its actual tests. A real trial merge with current integrationc977dab3 is clean and preserves all6 feature added/removed line sets. The selector/table file and actual probe gate are unchanged. Main's additional unnamed500 enum slot is excluded from27.x thunks/sleep RPCs. I reran the actual-C selector/probe fixture against the combined sources under ASan/UBSan:41/40/20 entries and0/0/21 gaps pass; unknown-build fallback, inverted missing-count and mandatory optional-query mutations all compile then fail at runtime.

Prior source/provenance and validation-only holds are resolved. Approving the build-selected tables and fail-closed27.3 behavior, with the reset caveat retained. No new kernel/QEMU/full integrated hardware boot or general27.3 qualification is claimed.