2 Commits

Author	SHA1	Message	Date
Lennart Poettering	daae8f858d	units: also require /dev/tpm0 to be around before tpm2.target can be reached ... While we typically just use /dev/tpmrm0 for accessing the TPM chip (i.e via the kernel's own resource manager), some sysfs properties that matter are on /dev/tpm0 only (i.e. the version without the kernel TPM resource manager). Hence, wait for both to show up in tpm2.target, so that we can be sure the full API is available. This matters because we want to access /sys/class/tpm/tpm0/ppi/request in the next commit.	2025-03-05 12:37:48 +01:00
Lennart Poettering	4e1f0037b8	units: add a tpm2.target synchronization point and small generator that pulls in ... Distributions apparently only compile a subset of TPM2 drivers into the kernel. For those not compiled it but provided as kmod we need a synchronization point: we must wait before the first TPM2 interaction until the driver is available and accessible. This adds a tpm2.target unit as such a synchronization point. It's ordered after /dev/tpmrm0, and is pulled in by a generator whenever we detect that the kernel reported a TPM2 to exist but we have no device for it yet. This should solve the issue, but might create problems: if there are TPM devices supported by firmware that we don't have Linux drivers for we'll hang for a bit. Hence let's add a kernel cmdline switch to disable (or alternatively force) this logic. Fixes: #30164	2024-01-03 13:49:02 +01:00