[DjDeveloperr]

Draft: validation pending (M5 lab boot queued). J313 testers are welcome now; the recipe is below.

Touch ID capture now waits on the sensor's data-ready interrupt only. The SPI polling fallback is gone, and there's no parameter to bring it back.

Until now the driver used the interrupt where the board described one and otherwise polled status every 2 ms (20 ms while waiting for a lift). That poll hid a broken description on the M5 Pro (J714s). Pin 138 was reserved in the DT, so gpiolib refused the mapping (didn't like hwirq-0x8a ... (rc=-6)), spi->irq ended up 0, and capture quietly polled. #1587 exposes that pin.

What changes

• Bring-up. Sensor bring-up now fails, with "the device tree must describe the sensor's data-ready line", instead of falling back to polling.
• Capture and finger-lift waits. They block only on the interrupt. Status is still read after each wake to gate every frame, and each wait is bounded (250 ms in capture, 20 ms for the lift), so a missed edge costs one wait.
• J613. The data-ready line is now described, from satchlj's J613 ADT (J613AP, 25G83: spi2/mesa interrupts = [0xc7, 0x3] on /arm-io/gpio0), as AP GPIO 199 rising, in t8122-j613.dts only. The power line (NUB GPIO 29) already matched. Untested on a J613 so far: J613 Touch ID works today on the poll path with arm64: dts: apple: t8122: SPI2 and SPI4 run from the 24 MHz reference, not 200 MHz #1598, and this PR moves it to the interrupt.
• J313. The data-ready line is now described, from its ADT (27.0.1, spi2/mesa interrupts = [104, 3] on the AP GPIO bank). Type 3 is the type every mesa node carries; the tree already describes J616c's and J713's as IRQ_TYPE_EDGE_RISING.

Boards whose data-ready pin is still pending

These have a mesa node but no interrupt in their DT, and no ADT is available yet. Touch ID won't come up on them with this change until their pin is described:

• J293 (MacBook Pro 13", M1)
• J493 (MacBook Pro 13", M2)
• J615 (MacBook Air 15", M3). It shares the J613 file, but its own pin isn't confirmed, so the J613 pin is deliberately not applied to it.

There is no polling fallback for these boards: the owner's call is that polling isn't an option in the driver. Each one needs its ADT's spi*/mesa interrupts and interrupt-parent; with those it's a two-line DT change.

Every other board with a mesa node describes its line: T600x, T602x, J413, J415, T604x, T6041, J700, T8132, J313, J613 and, with #1587, the J714s.

Testing on a J313 (MacBook Air M1) or J613 (MacBook Air 13", M3)

Use a kernel with both commits of this PR. Load apple_sep the way your install already does, with Touch ID set up as before.

1. Open the reader once (fprintd-list $USER), then check the kernel log: dmesg | grep -E 'apple_sep|apple-mesa' | grep -i -E 'interrupt|sensor'. Expect "sensor: data-ready interrupt configured" and no "no data-ready interrupt".
2. Read the line's count: grep apple-mesa-drdy /proc/interrupts (sum the CPU columns). The line should exist.
3. Enrol: run fprintd-enroll -f right-middle-finger $USER, or any finger not yet enrolled, and touch until enroll-completed. Read the count again: it should rise by several per touch.
4. Match: run fprintd-verify $USER and touch an enrolled finger. Expect verify-match; the count rises again.
5. Reject: run fprintd-verify $USER and touch a finger that isn't enrolled. Expect verify-no-match.
6. Please post the step 1 log lines, the counts before and after steps 3 to 5, and the three results here.

If step 1 says "no data-ready interrupt", the line isn't mapping. Post dmesg | grep -i 'hwirq\|pinctrl' so it can be traced; with this change the sensor won't capture without it.

Validation

• M5 (J714s), partial (no fingers; lab boot i3, 11-11 18:45, intg2 kernel with this module and arm64: dts: apple: t6050-j714s: Add the Touch ID sensor (and read its factory seal) #1587's DT):
  • The sensor's data-ready line maps: apple-mesa spi0.0: sep sensor: data-ready IRQ 185 configured for interrupt capture, and /proc/interrupts shows 185: ... Apple-GPIO 138 Edge apple-mesa-drdy. The earlier didn't like hwirq-0x8a refusal is gone.
  • Bring-up completes: diag sensor online, touchid ready. The two fingers enrolled before were restored.
  • The module has no polling path: no "falls back to SPI polling" string and no poll interval. Each capture blocks on the interrupt; the count rose by 12 per capture window (sensor registration at each window's start).
  • Enrol, match and reject with a finger were not run: no finger was available, by the owner's choice. That check moves to the J313 testers and to a later owner-attended run on the M5.
• J313: offered by two testers; see the recipe above.
• J613: IRQ path verified at probe; matching pending. satchlj ran one J613 boot with this PR at 85a964e, plus arm64: dts: apple: t8122: SPI2 and SPI4 run from the 24 MHz reference, not 200 MHz #1598 and a matching boot-loader DT. The data-ready interrupt is requested, and the sensor comes up without the polling fallback. The IRQ count went 3 → 13 over the probe transfers, with no storm. Enrol, match and reject on the interrupt path are still to run (no finger yet); the attended rows are planned for Thursday morning ET.
• Done so far: tools/aurora-sep/tests/test_log_ratelimit.py reports no new failures; its two existing ones are soc: apple: sep: bring the Touch ID sensor up afresh for each prompt #1536's lines, fixed by soc: apple: sep: rate-limit the two verify messages from the fresh bring-up #1590. The J313 DTB compiles, and the interrupt sits on the same controller as the sensor's power line.

🤖 Generated with Claude Code

[RyanTheTide]

Tested on J700 (T8140): one-shot kernel = integration 1de767b + this PR.

• DT has fingerprint@0 interrupts = <135 1>; driver logs data-ready interrupt configured; IRQ 169 (Apple-GPIO 135, edge) fires on each touch.
• No poll-path messages, no data-ready timeouts, no refused hwirq. SELinux enforcing, 0 AVC.
• Enrolled finger: verify-match (IRQ count 68 -> 84 over the touch). Different finger: verify-no-match (48 -> 67).

M2, M1 Pro and J616s results to follow.

[RyanTheTide]

Tested @ b40c9d8 on J616s, M2 and M1 Pro. Nobody touched the sensor on these three.

Test kernel: integration/aurora 990e00b with this PR's two commits cherry-picked. They don't apply to 1de767b, which lacks #1340 and #1536 in sbio.rs; 990e00b's sbio.rs, sep.rs and sensor_shim.c match this PR's base. Baseline: each Mac's production kernel (integration c6c15ac), same rows.

• J616s (T6040): DT has interrupts = <116 1>. The driver logs "sensor: data-ready interrupt configured", and apple-mesa-drdy sits on Apple-GPIO 116, edge.
• M2 (J413, T8112) and M1 Pro (J316s, T6000): the DT describes the line (<177 1> and <195 1>) and the GPIO controller maps it as an edge interrupt with no hwirq refusal. These two finish sensor bring-up, and request the interrupt, only at the first verify after a password, so the interrupt request and IRQ-only capture are still untested on them.
• All three on the test kernel: no polling messages, no "no data-ready interrupt", fprintd-list works, SEP no-finger self-tests 15/15, aurora-sep matches the baseline, s2idle 3/3 with fprintd-list after each resume and the self-tests 15/15 again, 0 SEP errors, 0 AVC, 0 failed units.

Two corrections to the J700 comment above. The J700 kernel was also 990e00b + this PR, not 1de767b. The "different finger" no-match came from fprintd: the enclave matched an enrolled finger, and fprintd rejected it because a different finger was requested. A non-enrolled finger hasn't been tried yet. The interrupt count rose on every touch (0 to 85 over five).

[DjDeveloperr]

Held on purpose (draft): the IRQ-only Touch ID capture driver is waiting for J313 testers to confirm the data-ready line on hardware.