On Fri, Oct 16, 2026 at 04:38:56PM +0000, Graf (AWS), Alexander wrote: > > 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 :).
To be exact, durations. In the context of TPMs, timeouts are the latency between the requested state changes. > > > Alex Br, Jarkko
