[maralcbr]

Summary

Commits the generator behind the MacBook support matrix so it can be refreshed each release candidate instead of rebuilt by hand.

+scripts/macbook-support-matrix/
+├── matrix.py      # stdlib CLI: scan, diff, build
+├── boards.json    # curated matrix: 42 boards × 16 features, gates and PRs per cell
+├── scan.json      # device-tree evidence at linux-aurora 8eddf5ae (refresh baseline)
+└── page.html      # page template
+agents/skills/macbook-support-matrix.md   # refresh procedure
+tests/test-macbook-support-matrix.{py,sh}
 AGENTS.md          # + task guide link

refresh(rc)
  scan  --kernel <linux-aurora at rc>   # cc + dtc: compile each MacBook .dts, effective status, driver match
  diff  --new scan                      # what moved since scan.json
  edit boards.json for each change
  build --out dir --scan scan           # index.html, basecamp.html, matrix-data.json
                                        # + lists cells the scan contradicts

Placement: the repo has no reports/, so code and data sit beside the other collectors in scripts/, and the procedure goes in agents/skills/ per the documentation layout in AGENTS.md. Bare #N and repo#N in notes become omacom PR links. boot_enables records nodes m1n1 turns on at boot (kboot.c:407-419, M3 Pro dispext, Neo), and tree_in_pr marks J714C, whose tree exists only in linux-aurora#404.

Evidence

• Before: the matrix lived as a one-off page plus scratch scripts with hardcoded paths.
  After: build reproduces the published data: 42 boards, every cell's status and note text identical to the current matrix-data.json. The one change is the M5 Pro / Max family note, now m1n1#30 instead of m1n1 #30 so the link points at m1n1. The page renders 42 boards in 13 families with no console errors.
• scan at linux-aurora 8eddf5ae (27 trees) matches the earlier scan on 566 of 567 cells. The other one is the new disabled J514M DCP node from linux-aurora#408, which the matrix already shows as In PR until m1n1#32.
• build --scan: 0 disagreements.
• tests/test-macbook-support-matrix.sh: 9 tests pass (link expansion, kind expansion for all 42 boards, effective DT status, build outputs, committed scan agrees with boards.json). They run in tests/all and need no dtc.

Merge Danger

Door: two-way

New files plus one AGENTS.md line; nothing at runtime or install time reads them.

Blast Radius: none

tests/all gains one suite, and it is stdlib only.

[greptile-apps]

Confidence Score: 4/5

[Low impact] The changes affect matrix readers and the maintainers who refresh it, not MacBook runtime behavior.

The PR has no blocking runtime defect, but the scan check, shared page text, and evidence links need cleanup.

Findings

1.  Bluetooth failures pass the check ▶
2.  Refreshed pages keep old claims ▶
3.  Kernel evidence links elsewhere ▶
4.  Summary evidence is not clickable ▶

Summary

Adds a repeatable MacBook support matrix workflow:

• Readers can compare support across 42 Apple Silicon MacBook models.
• Maintainers can refresh and rebuild the matrix from a kernel release candidate.

The review found a missed combined-feature check, duplicated release text that can go stale, and two evidence-link issues. Browser capture was blocked because the browser executable was unavailable.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Kernel[Kernel checkout] --> Scan[scan]
  Scan --> NewScan[New scan JSON]
  Baseline[Committed scan JSON] --> Diff[diff]
  NewScan --> Diff
  Diff --> Edit[Refresh boards.json]
  Edit --> Build[build]
  NewScan --> Check[Compare curated cells]
  Build --> Check
  Template[page.html] --> Build
  Build --> Outputs[Standalone HTML, Basecamp HTML, JSON]

Loading

_{Reviews (1) · Last reviewed commit: "Add the MacBook support matrix generator" · Reviewed by Greptile}

[greptile-apps]

Bluetooth failures pass the check

disagreements() accepts an On network cell when either Wi-Fi or Bluetooth has a driver. If Bluetooth changes to no-driver while Wi-Fi stays at driver, build --scan reports no disagreement. Maintainers can therefore miss a broken half of the combined feature. Require every listed feature to pass, with explicit exceptions for boards that need them.

[greptile-apps]

Refreshed pages keep old claims

The standalone page repeats release-specific summaries and evidence instead of reading them from boards.json. Following the refresh guide updates the table and Basecamp text but leaves these statements unchanged. For example, changing J514M to On still leaves the page saying it is waiting for m1n1#32. Generate the shared text from one source, or include the template in the required refresh steps.

[greptile-apps]

Kernel evidence links elsewhere

This note turns #404 into a link to m1n1/pull/404, because link() carries forward the repository from m1n1#37. The kernel change is linux-aurora#404. Spell out that repository here so both published outputs point to the right evidence.

Suggested change

	"m1n1 hand-off m1n1#37; no kernel driver in #404"
	"m1n1 hand-off m1n1#37; no kernel driver in linux-aurora#404"

[greptile-apps]

Summary evidence is not clickable

The standalone summary inserts PR references as plain text, so m1n1#31, linux-aurora#366, #390, and m1n1#32 are not clickable. Readers must find those PRs themselves. This misses the guide's requirement to link every PR and commit. Pass these strings through the same link expansion used for cell notes and Basecamp text.