On Fri May 17, 2024 at 5:53 PM EEST, Vitor Soares wrote:
> Greetings,
>
> I'm using the tpm_tis_spi.ko module and it is taking several minutes to probe on
> kernel:
> - commit ea5f6ad9ad96 ("Merge tag 'platform-drivers-x86-v6.10-1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86")
>
> root@verdin-imx8mm-07317726:~# time modprobe tpm_tis_spi
> [ 57.534597] SPI driver tpm_tis_spi has no spi_device_id for atmel,attpm20p
This was added in 6.9:
$ git --no-pager log -1 3c45308c44eda
commit 3c45308c44eda6cc3343a48341a82b96753c8a13
Author: Lukas Wunner <lukas@xxxxxxxxx>
Date: Sat Jan 13 18:10:52 2024 +0100
tpm_tis_spi: Add compatible string atmel,attpm20p
Commit 4f2a348aa365 ("arm64: dts: imx8mm-venice-gw73xx: add TPM device")
added a devicetree node for the Trusted Platform Module on certain
Gateworks boards.
The commit only used the generic "tcg,tpm_tis-spi" compatible string,
but public documentation shows that the chip is an ATTPM20P from Atmel
(nowadays Microchip):
https://trac.gateworks.com/wiki/tpm
Add the chip to the supported compatible strings of the TPM TIS SPI
driver.
For reference, a datasheet is available at:
https://ww1.microchip.com/downloads/en/DeviceDoc/ATTPM20P-Trusted-Platform-Module-TPM-2.0-SPI-Interface-Summary-Data-Sheet-DS40002082A.pdf
Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxx>
Cc: Tim Harvey <tharvey@xxxxxxxxxxxxx>
Signed-off-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
linux-tpmdd on tpm2_key
$ git describe --contains 3c45308c44eda
tpmdd-v6.9-rc1~2
> [ 57.560684] tpm_tis_spi spi2.1: 2.0 TPM (device-id 0x3205, rev-id 1)
> [ 57.584943] tpm tpm0: A TPM error (256) occurred attempting the self test
Course of event is I think:
rc = tpm2_do_selftest(chip);
if (rc && rc != TPM2_RC_INITIALIZE)
goto out;
/* 1. TPM_RC_INITIALIZE */
if (rc == TPM2_RC_INITIALIZE) {
/* 2. Branches here. */
rc = tpm2_startup(chip);
if (rc)
goto out;
rc = tpm2_do_selftest(chip);
if (rc)
goto out;
}
/* 4. Second self-test successful. */
It is possible that there is a performance regression given multitude
of HMAC changes. It would likely had to be in tpm2_do_selftest(), since
it is the most time-consuming function.
I checked the timeouts etc. but in the first seek did find anything
obvious.
BR, Jarkko
