[PATCH v2 08/10] tpm: Add the RNG child device
ilias.apalodimas at linaro.org
Fri Mar 4 15:15:19 CET 2022
> > >
> > > 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 . Issuing multiple startup
commands will just make the TPM respond with TPM2_RC_INITIALIZE. At
least that's my reading of 
More information about the U-Boot