Hi Ilias, On Thu, 1 Oct 2026 at 09:41, Ilias Apalodimas <[email protected]> wrote: > > Hi all, > > Any reason why we can't add this directly to the uclass probe instead? > According to our docs, the probe is supposed to 'make a device ready > for use'.
IIRC we talked about that a few years ago. Probing a device is supposed to get ready for using the hardware, so we typically have a separate operation to actually talk to it and get it into a particular state - otherwise just probing the device would take quite a while (it also means that TPM cannot be used for certain things after init() unless the board is reset!). The same approach is used by the keyboard, for example. But given that this keeps coming up, we could perhaps provide DM support for this sort of thing - it's not obvious the best way to do it in a generic way, though. We could have a DM flag and perhaps send an event that the TPM uclass picks up on? Regards, Simon > > Cheers > /Ilias > > On Thu, 1 Oct 2026 at 11:20, Simon Glass <[email protected]> wrote: > > > > Hi Michael, > > > > On 2026-09-30T09:05:12, Michael Haener <[email protected]> wrote: > > > tpm: Add an option to start the TPM during init > > > > > > Add CONFIG_TPM_AUTOSTART, which runs the TPM startup and self-test > > > sequence from an EVT_LAST_STAGE_INIT handler. This is the same thing the > > > 'tpm autostart' command does, but it does not depend on a boot script or > > > on the environment, so it cannot be skipped by a stale or edited env. > > > > > > Today a TPM is only started automatically when either CONFIG_MEASURED_BOOT > > > is used (and then only from bootm) or when booting via EFI with > > > CONFIG_EFI_TCG2_PROTOCOL. A plain booti/bootm therefore leaves the chip > > > uninitialised and the OS has to start it itself, which Linux reports as > > > "A TPM error (256) occurred attempting the self test". Boards have worked > > > around this by putting 'tpm autostart' into their environment, see > > > board/xilinx/zynqmp/zynqmp_kria.env. > > > > > > Boards that share one binary between variants with and without a TPM > > > fitted can enable this safely: when no TPM device is found the startup is > > > skipped silently. > > > > > > Signed-off-by: Michael Haener <[email protected]> > > > > > > drivers/tpm/Kconfig | 15 +++++++++++++++ > > > drivers/tpm/Makefile | 1 + > > > drivers/tpm/tpm_autostart.c | 33 +++++++++++++++++++++++++++++++++ > > > 3 files changed, 49 insertions(+) > > > > This seems like a good way to enable the TPM for boards that want it. > > It would be good to document this somewhere, e.g. where we mention > > MEASURED_BOOT > > > > > diff --git a/drivers/tpm/tpm_autostart.c b/drivers/tpm/tpm_autostart.c > > > @@ -0,0 +1,33 @@ > > > + /* A board may share one binary between variants without a TPM. */ > > > + ret = uclass_first_device_err(UCLASS_TPM, &dev); > > > + if (ret) { > > > + log_debug("No TPM found (err=%d)\n", ret); > > > + return 0; > > > + } > > > > It seems odd to ignore an error in this case - if the board maintainer > > says that a TPM must be present, then I would expect U-Boot to fail if > > it is not. > > > > In any case, uclass_first_device_err() also fails when the TPM is in > > the devicetree but fails to probe, e.g. because of a bus or GPIO-reset > > problem on a board that has the chip fitted. That is a real fault, but > > log_debug() hides it. Please can you stay silent only for -ENODEV and > > use log_warning() for anything else? > > > > > diff --git a/drivers/tpm/tpm_autostart.c b/drivers/tpm/tpm_autostart.c > > > @@ -0,0 +1,33 @@ > > > + ret = tpm_auto_start(dev); > > > + if (ret) > > > + log_warning("TPM startup failed (err=%d)\n", ret); > > > > tpm_auto_start() returns a u32, which may be a negative errno or a TPM > > response code (e.g. TPM2_RC_INITIALIZE). A response code printed in > > decimal from an int is hard to match against the spec, so please use a > > u32 and %#x here, as report_return_code() does for the tpm command. > > > > > diff --git a/drivers/tpm/tpm_autostart.c b/drivers/tpm/tpm_autostart.c > > > @@ -0,0 +1,33 @@ > > > +EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, tpm_evt_autostart); > > > > This is not really a driver, so lib/ (next to tpm_api.c) may be a > > better home than drivers/tpm. What do you think? > > > > Please can you enable this on sandbox and it would be nice to have a > > test in test/dm/tpm.c, checking that the TPM is started after init and > > that a missing TPM is handled. Your test could send the event. > > > > A full self-test on a TPMv2 can take a noticeable time, so the help > > should mention that this adds to the boot time on every boot, even > > when the TPM is not used. > > > > BTW, since the commit message mentions > > board/xilinx/zynqmp/zynqmp_kria.env, you could convert that board in a > > follow-up patch to show how the option is used. > > > > Regards, > > Simon
