Hi,
[...]
I think it is easier to just protect the child addition functions under CONFIG_TPM rather than create SPL_RNG and TPL_RNG symbols. We don't have any requirement for generating random numbers in the SPL and TPL stages. I feel that creating new symbols just for the sake of not putting a check for CONFIG_TPM is a bit of an overkill, especially since we do not have any requirement for RNG devices in the SPL/TPL stages.
What does checking for CONFIG_TPM have to do with SPL and TPL? If that option is enabled, the feature will be active in SPL and TPL too.
Maybe I am not explaining it properly. We need the addition of the RNG child device only in the u-boot proper stage, not in the SPL and TPL stages. The TPM uclass driver can indeed be built for the SPL and TPL stages, while the RNG uclass is needed only for u-boot proper. So, the addition of the RNG child device done in the TPM uclass driver should only happen in u-boot proper, and not in SPL/TPL stages. Which is the reason for the CONFIG_TPM check.
Also I see another problem, on further examination. You cannot start up the TPM in the pre_probe() function. That needs to be done under board control. E.g. for coral it happens in the TPL (or soon VPL) phase so cannot be done again in U-Boot proper.
I tested running the RNG command after the TPM device has already been probed and tpm_startup has been called. Even if I call the tpm_startup again, I do not see any issues. Does the TPM spec prohibit calling the initialisation function multiple times. I believe that the TPM device should be able to handle this scenario right?
[...]
We've already discussed this in [1]. Issuing multiple startup commands will just make the TPM respond with TPM2_RC_INITIALIZE. At least that's my reading of [2]
[1] https://lore.kernel.org/all/CAC_iWjLQmsGLLYfnDFq17-SD3RC7-Da-M41Qc5DjWp3XX9Z... [2] https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3-Comm... section 9.3.1
Regards /Ilias