task-44: piece 1 built; two corrections to the task's own premises

The staged vendor driver is the fpc_fingerprint variant, which blueline does
not build (b1c1_defconfig sets CONFIG_FPR_FPC=y, the other copy). The shipping
one has an empty vreg_conf[] and manages no regulators at all.

The TZ pointer was wrong: secure_load_tz_frontier.md is superseded and covers
hyp-assign/XPU, not TA loading. tz_listener_archaeology.md plus the four
qseecom commits are the record, and they already show TZ answering us -
version query succeeds, listener 0x5000 registers live. What is missing is
app loading, not the channel.

Pins confirmed against this unit's DTBO; the FPC1075 caution is resolved.

docs/tasks/44-fingerprint-fpc1020.md

@@ -1,24 +1,39 @@
 # TASK 44 — Fingerprint (FPC1020) as a capability factor
 
-**Status:** open, raised 2026-07-28 (Casey: "a huge win possible"). **Size:**
-two separable pieces — one is a session, the other is a research frontier.
-Do not scope them as one thing. **Repos:** `Pixel3Arch` (kernel + DT),
-`souveraine` (the factor, if the second piece lands).
+**Status:** piece 1 **built and compiling** 2026-08-01, unverified on glass;
+piece 2 open. Raised 2026-07-28 (Casey: "a huge win possible"). **Size:** two
+separable pieces — one was a session, the other is a research frontier. Do not
+scope them as one thing. **Repos:** `Pixel3Arch` (kernel + DT), `souveraine`
+(the factor, if the second piece lands).
 
-## The substrate is already extracted, and nobody wired it
+## The substrate was extracted — but from the wrong driver
 
-`Pixel3Arch/staging/fingerprint/` has held this since 2026-07-07 and it has
-never been referenced by a build:
+`Pixel3Arch/staging/fingerprint/` held this from 2026-07-07 and was never
+referenced by a build. Two corrections came out of actually wiring it
+(2026-08-01):
 
-```
-fpc1020_platform_tee.c   16K   vendor driver
-sdm845-blueline-fingerprint.dtsi  the DT node, verbatim from downstream
-Kconfig  Makefile
-```
+**1. The staged `fpc1020_platform_tee.c` is the variant blueline does not
+build.** LOS carries two copies, and `staging/`'s is byte-identical to
+`drivers/input/misc/fpc_fingerprint/`. `b1c1_defconfig` sets
+**`CONFIG_FPR_FPC=y`** — the *other* one,
+`drivers/input/misc/fpr_FingerprintCard/`. The difference is load-bearing:
+the shipping driver's `vreg_conf[]` is **empty**, so `ARRAY_SIZE` is 0 and
+`device_prepare()` manages **no regulators at all**. The rail is always-on and
+the vendor deliberately gutted the table. Anything scoped around this driver's
+power management was scoped around code that does not run on this phone.
 
-The DT snippet is complete and specific — `fpc,fpc1020` on TLMM, reset on
-gpio7, IRQ on gpio121, `vdd_io` off `pm8998_s4`, three pinctrl states. That is
-the hard-to-derive part and it is already written down.
+**2. The pin list is confirmed, and the FPC1075 caution below is resolved.**
+This unit's own DTBO (`~/pixel3-work/dtbo_9.dts`, fragment@40, `fp_fpc1020`)
+carries `compatible = "fpc,fpc1020"`, `fpc,gpio_rst = <… 0x07 …>`,
+`fpc,gpio_irq = <… 0x79 …>` (121), `vdd_io-supply = <&pm8998_s4>`. Identical to
+LOS's own `sdm845-b1c1-fingerprint.dtsi`. There is no FPC1075 on this board and
+nothing reserves GPIO 81–84.
+
+Note `pm8998_s4` is a **downstream label that does not exist in our tree** —
+the same rail is `vreg_s4a_1p8` (a `regulator-fixed`, always-on, boot-on 1.8 V).
+The staged `.dtsi` also uses the retired `mux {}`/`config {}` pinctrl style and
+`fpc,gpio_*` properties that gpiod cannot resolve, so it could never have been
+included as written.
 
 ## Read the driver before planning around it
 
@@ -32,17 +47,36 @@ sees a ridge image; it sees "a finger arrived" and later "the TA says yes."
 That single fact splits this task, and it is why the two halves must not share
 a schedule.
 
-## Piece 1 — the sensor as an input and a wake source (a session)
+## Piece 1 — the sensor as an input and a wake source (BUILT 2026-08-01)
 
-Wire the DT node, build the shim, and the phone gains a real button under the
-reader: a finger on the sensor raises an interrupt the AP can act on. That is
-worth having on its own — back-tap, wake, a shortcut — and it is the whole
-`FIRST-CLASS-APPS` treatment of any other input.
+Written as `drivers/input/misc/fpc1020.c` on the `fingerprint-fpc1020` branch
+of `linux-blueline` (`6f637c4c2`), not as a copy of the staged vendor file. The
+2015 original cannot compile here: `of_gpio.h` is gone, `wakeup_source_init`
+/`_trash` are gone, `platform_driver.remove` returns void. The port uses
+descriptor GPIOs, `devm_pm_set_wake_irq`, and an implicit `default` pinctrl
+state in place of the three named reset/irq states.
 
-Acceptance: `dmesg` shows the device probing, `wakeup_enable` arms it, and a
-touch produces an event userspace can consume. Route it through the
-gesture/keyboard routing system, never a hardcoded binding (INTERFACE-
-ARCHITECTURE §4) — TASK-13 fought exactly this and the rule came out of it.
+**The vendor sysfs surface is not shipped** — no `device_prepare`, `hw_reset`,
+`regulator_enable`, `clk_enable`, `irq`. That is a control interface for a TA
+which is not loaded here, and a `poll()`-driven sysfs node is not how input is
+routed on this device. The driver registers an input device reporting
+**`KEY_WAKEUP`** instead, which puts the reader on the same evdev path as
+everything else — so it becomes a row in the existing gesture table rather than
+a new hardcoded branch (INTERFACE-ARCHITECTURE §4). TASK-13 fought exactly this
+and the rule came out of it.
+
+DT is in `sdm845-google-blueline.dts`: `interrupts-extended = <&tlmm 121
+IRQ_TYPE_EDGE_RISING>`, `reset-gpios = <&tlmm 7 GPIO_ACTIVE_LOW>` (active-low —
+the polarity trap that cost a day on FTS, `PAF/touch.md`), `vdd_io-supply =
+<&vreg_s4a_1p8>`, plus an `fp-default-state` pinctrl group.
+`CONFIG_INPUT_FPC1020=m` is in `kernel/config-blueline.aarch64` and survives
+`olddefconfig` in place, so the PKGBUILD drift guard stays quiet.
+
+**Done:** compiles clean on archdev (zero warnings); the DTB builds and
+decompiles back to the right phandles, pins and flags.
+**Not done — needs the device:** a probe line in `dmesg`, an interrupt on
+finger contact, and a wake from a blanked screen. Until a touch has actually
+produced an event this is a driver that builds, not a sensor that works.
 
 **This piece does not authenticate anything.** Do not let it get described
 as fingerprint unlock, in a commit or a settings string. An input that looks
@@ -51,13 +85,48 @@ like an auth factor and is not is worse than no input.
 ## Piece 2 — biometrics, which is a TrustZone question
 
 Matching needs either QSEECOM and Google's TA, or an open SPI image path with
-our own matcher. Neither exists here today. Before any of it is scheduled,
-answer one question: **can we load and talk to a TZ application at all on this
-device?** `PAF/evidence/secure_load_tz_frontier.md` is the standing record of
-what TrustZone does and does not let us do — read it first; the modem's
-secure-load fight is the same wall from the other side.
+our own matcher. Neither exists here today.
 
-If the answer is no, the honest outcome is Piece 1 plus a note, and face auth
+**Correction 2026-08-01 — this section used to point at
+`PAF/evidence/secure_load_tz_frontier.md`. That is the wrong doc.** It is
+marked SUPERSEDED at the top and it is about `qcom_scm_assign_mem` returning
+−22 and the modem's XPU faulting — memory *ownership transfer*, a different SCM
+surface from loading and calling a TA. It answers nothing here. The standing
+record for this question is **`PAF/evidence/tz_listener_archaeology.md`** plus
+the four `qseecom:` commits on the `blueline` branch.
+
+Read together, they say the question is **half answered, and better than
+expected**:
+
+- `google,blueline` is in `qcom_scm_qseecom_allowlist`; **the QSEECOM version
+  query already succeeds on this device** (`2e172dcb3`). TZ answers us.
+- **Listener registration works against this device's real signed TZ image** —
+  id `0x5000` (ssd) returns `QSEECOM_RESULT_SUCCESS`, live-tested 2026-07-02.
+  The archaeology doc had listed "whether this exact signed TZ image accepts
+  registration from a differently-built AP driver" as unknown and untestable
+  without trying it. It was tried. It works.
+- `/dev/qseecom` exists with `GET_APP_ID` + `SEND_CMD` wrapping
+  `qcom_scm_qseecom_app_get_id`/`_app_send` (`5fa36934b`) — but that commit
+  says plainly: **compiles clean, never run on hardware.**
+
+So what is actually missing is narrower than "can we talk to TZ":
+
+1. **There is no app-*loading* path.** `5fa36934b` only queries already-resident
+   apps; it deliberately is not the Android load-app ABI and does no ELF
+   loading. `QSEECom_start_app`/`load_external_elf` is the one family the
+   archaeology explicitly never disassembled.
+2. **Nothing has ever exercised `app_send` live**, so the blocked-call resume
+   path (`8f737e819`) is unproven end-to-end.
+3. The FPC TA blob and its command protocol are still vendor-opaque.
+
+Cheapest next probe, and it is small: run the existing `/dev/qseecom`
+`GET_APP_ID` against candidate names on the device. `uefisecapp` is already
+confirmed ENOENT; downstream loads keymaster as `'keymaste'`. If *any* name
+resolves, resident-app calling is real and only FP-specific work remains. If
+none does, apps must be loaded before they can be called, and that is the
+frontier — not the SCM channel.
+
+If the answer stays no, the honest outcome is Piece 1 plus a note, and face auth
 (TASK-12) is the cheaper capability factor. Say so rather than leaving this
 open forever.
 
@@ -74,14 +143,23 @@ permission/capability gating is in-tree, not vendored.
 - **Do not build Piece 2 first.** The cheap win is real and independent.
 - **Do not ship the shim's sysfs to userspace as an API.** It is a vendor
   interface for a TA that does not exist here; a settings switch bound to
-  `device_prepare` would be a success-shaped control over nothing.
-- **Do not confuse FPC1020 with the FPC1075** the blueline DTS reserves
-  GPIO 81–84 for. Check which part this unit actually carries before trusting
-  either pin list — the haptics task (TASK-45) has the same pin-conflict
-  problem in the same GPIO neighbourhood.
+  `device_prepare` would be a success-shaped control over nothing. The port
+  drops that surface entirely — do not add it back for convenience.
+- ~~**Do not confuse FPC1020 with the FPC1075**~~ — RESOLVED 2026-08-01. This
+  unit's own DTBO carries FPC1020 on gpio7/gpio121 and nothing reserves
+  GPIO 81–84. TASK-45's pin-conflict problem (GPIO 85/86, SE5) is real and
+  separate; it is a neighbouring range, not this one.
+- **Do not take `staging/fingerprint/` as the reference.** It is the
+  `fpc_fingerprint` variant, which blueline does not build, and its `.dtsi`
+  uses downstream labels and retired pinctrl syntax. The authority is
+  `references/los-kernel-blueline-4.9/drivers/input/misc/fpr_FingerprintCard/`
+  plus this unit's DTBO.
 
 ## Connects to
 
 TASK-12 (face auth — the other capability factor, and the fallback if TZ says
 no), TASK-40 (what a biometric stream permits inferring), `SECURITY-AUDIT.md`,
-`SESSION-AUTHORITY-DOCTRINE.md`, `PAF/evidence/secure_load_tz_frontier.md`.
+`SESSION-AUTHORITY-DOCTRINE.md` **§2** (reveal-on-lock-surface — "a fingerprint
+touch reveals personal content *in place*, without unlocking the session" — is
+gated on this sensor; piece 1 does not deliver it, piece 2 does),
+`PAF/evidence/tz_listener_archaeology.md` (the TZ record that actually applies).