On 16.10.26 18:27, Jonathan McDowell wrote: > On Fri, Oct 16, 2026 at 04:37:33AM +0000, Surendran Kanagaraj wrote: >> TPM commands need to complete within the command duration defined in >> the TPM2 spec or keep answering TPM2_RC_RETRY for at most >> TPM2_DURATION_LONG (2s). >> >> In rare scenarios NitroTPM can enter a mode where it either sends >> TPM2_RC_RETRY for more than 2s or delays command completion. When >> this happens during auth session start, the driver disables the chip >> and every subsequent request fails: >> >> tpm tpm0: in retry loop >> tpm tpm0: tpm2_load_context: failed with a TPM error 0x0922 >> >> Add support for vendor duration overrides to the CRB driver, based on >> the vendor ID read from the interface ID register. For NitroTPM, raise >> TPM_SHORT, TPM_MEDIUM and TPM_LONG to 30s which covers the longest >> unavailability time along with some headroom. > Bumping all of these to 30s seems excessive. Is it really the case that > all commands can potentially take this long? Is that because of > non-TPM-related operations Nitro might be doing behind the scenes?
We won't reach the 30s, which is exactly why it's a safe default for the safety net that these timeouts are :). Alex
