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? James
