[ludagoo]

Describe the J313 Touch ID data-ready line as a rising edge on pinctrl_ap pin 104, and stop the first post-wake verify from registering the sensor twice when that registration is still held.

On a 13.5 profile, attach wakes and patches the sensor without calibrating. The first verify then power-cycled, calibrated, and registered again. The driver now keeps a registration it left powered when the patch is still acknowledged and the state is not NEEDS_PATCH, and reloads after calibration only when that status is gone. Capture uses the interrupt once the sensor is patched and idle, instead of SPI polling.

Machine: MacBook Air (M1, 2020), J313.

Session build, Monday 26 Oct 2026 05:02 PM -03: linux-aurora 7.2.11-6-2-ARCH (package 7.2.11.aurora6-2), branch local/j313-test at 7638df0. makepkg exited 0. rustc 1.85.0, LLVM/clang 18.1.8. This machine is running that kernel. The stacked commit compiled in was 81183b2. This pull request's head is 07c98ef, which is not the commit that was built.

sep.o was compiled at 16:04 in that build, and lsmod shows apple_sep loaded. The earlier note that the patched Rust was never compiled is stale.

Touch ID after a real sleep still needs fprintd-verify. That has not been run.

[malik-na]

Tested on a J313 (M1 Air): builds and boots. The changed code can't be reached on a stock Omarchy install.

• The patched Rust compiles (7.2.11-lab-pr223 built cleanly with the Air's config). The description said it hadn't been compiled.
• Two boots: all lab tests passed, omarchy-m-test showed 0 regressions, and there were no SEP errors.
• On both boots the SEP sensor path never ran: there's no sensor bring-up in dmesg, and pinctrl_ap pin 104 doesn't appear in /proc/interrupts. On this install apple-sep isn't loaded and /dev/sep-bio doesn't exist. Omarchy's touchid-status records unsupported:m1-family and won't offer to turn Touch ID on, so nothing attaches to the sensor.
• So attach-time configure_data_ready(), the held registration and interrupt-driven capture are all untested here. Testing them on J313 needs the driver loaded outside Omarchy's gate.

How this was tested

• MacBook Air (M1, 2020), J313, DCP 13.5, BCM4378, booted through U-Boot → Limine.
• This PR's head and its parent 19f4965180f4 (the baseline), built with the Air's own /proc/config.gz and booted as one-shot test entries. The Mac returns to its installed 7.2.11-6-1-ARCH after every run.
• Automated boots: device-phase suspend (pm_test=devices), omarchy-m-test, and a check script (dmesg counters, keyboard and panel backlight writes, ALS channels, two nmcli con up re-associations, one pm_test=platform s2idle cycle).
• Hands-on boots: a person at the Mac doing a real lid-close sleep and keypress wake, using the brightness keys, and covering or lighting the ALS, while the kernel's state was logged every 2 s.
• Tested commit: d2498ea3741f on 19f4965180f4. The PR has since been rebased to 07c98efa67e5 on 937b727ef9a3 with an identical diff; the new base wasn't re-tested.

[malik-na]

Follow-up: tested Touch ID on J313 with this PR merged with #180 on 937b727ef9a3, using #180 to boot the enclave.

• Gate: to make touchid-eligibility return available on t8103, the m1-family block had to come out and t8103 had to go on the board allowlist that follows it. Commenting out only the m1-family block leaves the next elif dangling, and the M1 then fails as unsupported:board.
• Read-only boot (soc: apple: sep: boot the enclave on every Mac (fixes the M1/M2 microphones, #141) #180 defaults): the enclave boots (TZ0 accepted, IMG4 acknowledged, 7 endpoints). There's no /dev/sep-bio and no sensor bring-up, and the pinctrl_ap pin-104 IRQ isn't registered.
• xart_writes=1 provision_keybag=1: identity-keybag provisioning fails at the xART guard, so /dev/sep-bio never appears and the sensor path in this PR can't run:

apple_sep: xART guard level 1: 11 session records exist, 0 created by Linux; the other 11 are protected
apple_sep: xART guard: refused to rewrite a kind-4 record this Linux install did not create
apple_sep 242400000.sep: sks: CREATE_KEYBAG reply carried no parsable body: mailbox status -1, response 0 bytes, response_size 0
apple_sep 242400000.sep: bringup: identity-keybag provisioning failed; no retry this boot

So on M1 this PR can't be tested until keybag creation gets past the guard. That's the blocker Scott described, and the log shows it's the kind-4 rewrite specifically. No xART write was logged, and the store summary (13 live records, max revision 21157) was the same before and after.