[DjDeveloperr]

Touch ID on the MacBook Pro 14" M5 Pro (J714s). The T6050 SEP profile was already in integration (#1325). Two gaps kept the sensor from coming up:

1. Device tree. The J714s DT didn't describe the sensor.
   • The ADT puts J616s's Mesa sensor (sensor-id 0x3356) on spi2 at 0x505108000: 8 MHz, chip select 0, power on NUB GPIO 21 (function-mesa_pwr), data ready on AP GPIO 138.
   • nub_gpio0 is now a GPIO and interrupt controller, as on T604x. Its power state comes from the always-on PMGR (ADT NUB_GPIO, 0x288300088).
   • On the J714s: that bank, spi2 and its power state are enabled, and fingerprint@0 is added with J616s's timing and SPI mode.
   • AP GPIO 138, the data-ready line, is exposed in the board's gpio-reserved-ranges, next to the pins J714s: sound through the AOP (speakers and headphone jack) #1554 exposes. While it was reserved, gpiolib refused the mapping (didn't like hwirq-0x8a ... (rc=-6)) and the sensor had no interrupt. Pin 112 and everything else stay reserved.
   • spi2 runs from the 24 MHz reference: ADT clock-ids 451 is 24 MHz in the arm-io clock table, the same as clkref. The PMGR clock provider it named has no driver.
2. aurora-touchid-setup. It refused this Mac's factory seal, so it couldn't rebuild the calibration and the sensor root key.
   • The seal's IM4M holds its MANB objects in a SEQUENCE, not the SET image manifests use, and it names a record kind once per record (two scrt).
   • The parser now accepts a SEQUENCE. A name repeated there keeps no properties, so nothing is admitted from it; a duplicate in a SET is still refused.
   • The seal is still embedded unchanged, so the enclave checks the factory bytes as before.
   • The distro packages carry byte-identical copies of this tool and pick the fix up when they sync.

Validation on the J714s

Rebased onto integration/aurora e3fb611 (after #1554). With phandles kept symbolic, the J714s DTB differs from the base only by the Touch ID nodes, spi2 and its power state, nub-gpio0, and pin 138.

The kernel was 7.3.0-m5-intg2. A chainloaded lab boot used a DTB built from this branch: the default DTB plus exactly these nodes. apple-sep and spi-apple came from integration cdd7ccf. SEP ran as the working machines run it: xart_writes=1 provision_keybag=1, the platform's guard (level 1).

Check	Result
Bring-up	nub-gpio0 binds apple-gpio-pinctrl. The sensor binds at 8 MHz, mode 2, with hardware CS timing 20 ns. The SEP has 12 endpoints.
Setup	aurora-touchid-setup rebuilt mesacal-j714s.bin and msrk-j714s.bin from the factory records; the second run reports "identical to the rebuild".
Enrol, first boot	fprintd enrolled the right index (about 12 touches); the enclave reports 1 identity.
After a reboot	"Touch ID: restored 1 enrolled identity; enrolment survived reboot".
Enrol, after the reboot	The left index enrolled.
Verify, after the reboot	The right index matched.
Wrong finger	Another finger was rejected (verify-no-match).
Tests	tests/test_touchid_setup.py passes 50/50; the new cases fail on the old parser.
DT	No new dtc warnings. The other T6050 boards build, and ADT coverage for J716s and J873s is unchanged.

Capture currently polls: the driver logs "no data-ready interrupt" even with the node's interrupt described. That's a follow-up; enrol and match work either way.

SEP state written in the validation runs

• xART. The guard was at level 1 throughout: 12 session records before and after, none created by Linux, no refusals, and the keybag creation window was never used. No existing session record was rewritten or deleted. Only the shared root records advanced (14 live records throughout).
• Enclave. One identity keybag and the machine ref-key were created, two fingers were enrolled, and lockout records were saved.
• Linux root. The driver's own state under /var/lib/aurora-sep*, plus fprintd's records.
• Not touched. No xART payload was read or copied, and no macOS volume was written.
• Default boot. The default command line still runs SEP read-only.

🤖 Generated with Claude Code

[DjDeveloperr]

The source failure is integration's own, not this PR's. tools/aurora-sep/tests/test_log_ratelimit.py fails on integration/aurora 6626776 by itself. Two dev_info! calls in sbio.rs ("bringing the sensor up afresh instead of reusing it" at 2671, "the sensor reset under the capture" at 3048, both from #1536) sit on the request path that the rate-limit test (from the sep-log-ratelimit-v2 branch) checks. This PR doesn't touch sbio.rs. Its own test file, tests/test_touchid_setup.py, passes 50/50.