[qcom-next][glymur-crd] Device taking time to reach to shell

[sgaud-quic]

Glymur-crd device is taking time to reach shell, increase of approximately 2 mins is observed :
Branch : qcom-next
Kernel Version : v7.1-rc4
LAVA Job : https://lava.infra.foundries.io/scheduler/job/231712

Systemd is waiting for /dev/tpm0 for 90 secs, leading to bootup time to exceeds 2 mins to reach shell :

M
[K[    [0;31m*[0;1;31m*[0m] (1 of 2) A start job is running for /dev/tpm0 (1min 27s / 1min 30s)
M
[K[     [0;31m*[0m] (2 of 2) A start job is running for /dev/tpmrm0 (1min 27s / 1min 30s)
M
[K[    [0;31m*[0;1;31m*[0m] (2 of 2) A start job is running for /dev/tpmrm0 (1min 28s / 1min 30s)
M
[K[   [0;31m*[0;1;31m*[0m[0;31m*[0m] (2 of 2) A start job is running for /dev/tpmrm0 (1min 28s / 1min 30s)
M
[K[  [0;31m*[0;1;31m*[0m[0;31m* [0m] (1 of 2) A start job is running for /dev/tpm0 (1min 29s / 1min 30s)
M
[K[ [0;31m*[0;1;31m*[0m[0;31m*  [0m] (1 of 2) A start job is running for /dev/tpm0 (1min 29s / 1min 30s)
M
[K[[0;31m*[0;1;31m*[0m[0;31m*   [0m] (1 of 2) A start job is running for /dev/tpm0 (1min 30s / 1min 30s)

[sgaud-quic]

Analysis so far :

87a1698cb806

Adding glymur-crd to the QSEECOM allowlist causes qcom_scm to fully
initialize at early boot, which sets up uefisecapp and registers EFI
variable operations. This makes efi_has_tpm2() succeed by reading the
LoaderTpm2ActivePcrBanks EFI variable, satisfying ConditionSecurity=tpm2
in systemd.

As a result, systemd activates tpm2.target which unconditionally waits
for /dev/tpm0 and /dev/tpmrm0.
systemd waits the full 90-second timeout for each of the two
TPM device units, pushing total boot time beyond 2 minutes.

[lool]

workaround: pass systemd.tpm2_wait=0 on kernel cmdline