Hi Tom On Thu, 1 Oct 2026 at 20:27, Tom Rini <[email protected]> wrote: > > On Thu, Oct 01, 2026 at 05:03:31PM +0100, Simon Glass wrote: > > 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? > > I'll let Ilias weigh in here, but I feel like maybe we've just been > treating TPM wrong and it should just be on-probe.
I can buy into the argument: 'The TPM self test is slow and i might want to skip it'. However, I don't see why people who care about boot speed and not the TPM and don't want the extra security layer don't just disable it from the DT. Probing it at the uclass or an event or a cmd makes no difference, it just complicates our code. If anyone has a use case in mind that I am missing please shout. Cheers /Ilias > > -- > Tom
