Dear kernel team,

please enable, on arm64 (and ideally generically):

  CONFIG_TCG_FTPM_TEE=m

This single module is the only thing preventing a fully working TPM 2.0
on the growing class of ARM SBCs that ship a standards-compliant UEFI
firmware (mainline TF-A + OP-TEE + U-Boot, SystemReady-IR style) with the
Microsoft fTPM reference implementation running as a trusted application
inside OP-TEE. On such boards the firmware performs TCG2 measured boot and
hands Linux the event log (visible as the EFI TPMEventLog / TPMFinalLog
config tables); systemd 257 in trixie is fully TPM2-capable
(systemd-cryptenroll, pcrlock, LUKS2 token plugins). The missing driver is
tpm_ftpm_tee.

Details that make this a low-risk change:

- drivers/char/tpm/tpm_ftpm_tee.c is a small, self-contained proxy driver.
- It depends only on TEE && OPTEE, both already =m in the Debian config
  (CONFIG_OPTEE=m), so it adds a module and nothing else when built.
- It has zero cost on systems without an OP-TEE fTPM: it binds via
  TEE-bus enumeration of the fTPM TA UUID
  (bc50d971-d4c9-42c4-82cb-343fb7f37896) and simply never probes if that
  TA is absent.
- Upstream precedent: the arm64 defconfig gained it in Feb 2026
  (patchew.org/linux/20260211060639.446898-1-a-dubey@ti.com/).

Verified on a Radxa ROCK 5B running mainline-based UEFI firmware: with a
DKMS build of exactly this module, /dev/tpm0 appears, the firmware event
log populates /sys/kernel/security/tpm0/binary_bios_measurements, and
"bootctl status" reports "TPM2 Support: yes". Shipping the module in the
Debian kernel removes the need for any out-of-tree build.

Optional, separate follow-up (NOT required for the above to work):

  CONFIG_RPMB=y

This enables in-kernel RPMB routing so the fTPM's secure storage does not
need a userspace tee-supplicant. Without it, RPMB is served by
tee-supplicant, which works. If enabled it should be =y not =m, because
MMC_BLOCK has "depends on RPMB || !RPMB" and RPMB=m would demote the
built-in MMC_BLOCK; as =y it is a small in-kernel class with no cost on
systems lacking RPMB hardware.

Thanks!