Re: [PATCH v2 2/2] tpm_crb: Raise durations for Amazon NitroTPM

[Jarkko Sakkinen <jarkko@kernel.org>]

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