Hello Lukas, On Wed, Nov 22, 2023 at 12:29:49PM +0100, Lukas Wunner wrote: > On Wed, Nov 22, 2023 at 12:33:58AM +0100, Francesco Dolcini wrote: > > On Tue, Sep 26, 2023 at 09:09:36PM +0200, Lukas Wunner wrote: > > > Normally the platform firmware is responsible for taking a Trusted > > > Platform Module out of reset on boot and storing measurements into it. > > > > > > However if the platform firmware is incapable of doing that -- as is the > > > case on the Raspberry Pi -- then the onus is on the kernel to take the > > > TPM out of reset before trying to attach a driver to it. > > > > > > Provide a reset driver for such platforms. > > > > > > The Infineon SLB9670 TPM requires a specific reset sequence on its RST# > > > pin which is documented in sections 5.4 and 5.5 of the datasheet: > > > > Are you really sure that this change is required? > > I have seen the RST# Timing diagram in the datasheet, however I wonder > > if a reset is required at all during power-up, for example. > > If the RST# pin is not toggled at all upon a warm reset (reboot), > the TPM will remain in whatever state it was during the previous boot. ... > Also, the pin controller connected to RST# might be reset upon a reboot > (think of a SoC internal pin controller setting all its registers to 0) > and RST# might be asserted as a result. It is then necessary to take > the TPM out of reset. Toggled at boot is different from what you are doing here. > > Not to mention that I was able to see the driver probe succeed in a > > similar setup to the one you are describing in the commit message > > (different board, arm64, but nothing done by the platform firmware). > > Hm, is the RST# pin even connected on that board? Yes, it's connected and it is asserted/de-asserted (aka toggled) during startup from the HW reset circuit. However this is not implementing the reset sequence you are implementing here. Francesco
