Hi, On Thu, Apr 25, 2024 at 09:24:48AM -0400, James Bottomley wrote: > On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote: > [...] > > General purpose distros typically don't build all TPM drivers into > > the kernel, but ship some in the initrd instead. Then, udev is > > responsible for iterating all buses/devices and auto-loading the > > necessary drivers. Each loaded bus driver might make more devices > > available for which more drivers then need to be loaded, and so on. > > Some of the busses are "slow" in the sense that we don't really know > > a precise time when we know that all devices have now shown up, there > > might always be slow devices that haven't popped up yet. Iterating > > through the entire tree of devices in sysfs is often quite slow in > > itself too, it's one of the most time consuming parts of the boot in > > fact. This all is done asynchronously hence: we > > enumerate/trigger/kmod all devices as quickly as we can, but we > > continue doing other stuff at the same time. > > So let me make a suggestion that you can use now. Since all you > currently care about is the EFI/ACPI device, there is always a single > sysfs entry that corresponds to that (so you shouldn't need the log > entry as an indicator): > > /sys/bus/acpi/devices/MSFT0101\:00 > > That link (or a kobject uevent if you prefer to look for that) will > always appear regardless of whether a driver has attached or not. When > the driver actually attaches, a driver/ directory will appear where the > link points. > > The device link is added when the acpi scan is initiated as a > subsys_initcall, which is before all the filesystem initcalls, so it > should run before the initrd is mounted. > > Is this enough for now and we can think about a more generic indicator > that all drivers have been probed later? This covers EFI ACPI devices but not devices without ACPI. Some boards have the TPM device data in devicetree. Some boards have a firmware TPM which is not listed in devicetree but is detected at runtime once optee drivers, tee-supplicant, etc have loaded. Based on the comments here, I could propose a v2 with TPMFinalLog based sysfs file which is empty but existence of the file shows to systemd that EFI firmware used a TPM device and that can queue in the normal ACPI, devicetree or other mechanisms of detecting the real TPM device, loading drivers and possibly needed userspace components like tee-supplicant for optee and fTPM. I don't know how non-EFI firmware could be supported, unless they show the ACPI TPM entry. Cheers, -Mikko