Hi Jarkko, > > Unfortunately, when these components are built as built-in drivers, > > the functions ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are > > all executed during the device_initcall phase. > > As a result, if crb_acpi_driver_init() is called before the ffa_device > > exists or > > has been probed, it returns -EPROBE_DEFER, > > Please mention exactly this in the commit explicitly and then it should > be in detail enough.
Okay. I'll add this in the next round in cover letter. > > > causing the probe to be deferred and retried later > > during the deferred_probe_initcall phase. > > OK, if ffa_init() is leveled up in the initcall hierarchy, shouldn't > that be enough as long as ko's can be found from initramfs? As you mentioned, this is handled in Patch #1. However, although ffa_init() is called first, unless tpm_crb_ffa_init() is also invoked, crb_acpi_driver_init() will fail with -EPROBE_DEFER. Please note that IMA is always built-in and cannot be built as a module. To generate boot_aggregate with TPM PCR values from 0 to 7, the TPM-related modules must also be built-in and properly initialized before init_ima(), which internally calls ima_init(). To ensure this, Patch #2 adds a routine to probe the ffa_device() in tpm_crb_ffa_init(). This allows crb_acpi_driver_init() to successfully complete even if it is called first, because tpm_crb_ffa_init() triggers probing of the ffa_device via ffa_register() beforehand. Thanks. -- Sincerely, Yeoreum Yun
