On Sat, Oct 17, 2026 at 03:12:10AM +0300, Jarkko Sakkinen wrote: > On Fri, Oct 16, 2026 at 04:37:32AM +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). > > > > Devices that have different timeout requirements than the TPM2 spec > > could exhaust the retry budget or exceed the command duration. These > > failures disable the device during an auth session, failing all > > subsequent TPM requests. Worse, when a TPM2_CC_FLUSH_CONTEXT command > > fails, it leaks the TPM's transient memory: > > > > tpm tpm0: in retry loop > > tpm tpm0: tpm2_load_context: failed with a TPM error 0x0922 > > ... > > tpm tpm0: A TPM error (2338) occurred flushing context > > > > Fix this by overriding the command durations and retry budget > > based on chip->duration and letting the driver modify the durations > > during tpm2_get_timeouts() as TPM 1.x does. Chips without > > the override keep the current durations. > > > > Tested in QEMU with swtpm on tpm_crb, tpm_tis, tpm_tis_i2c, tpm_ibmvtpm > > and tpm_vtpm_proxy. > > > > Assisted-by: LLM > > Signed-off-by: Surendran Kanagaraj <[email protected]> > > --- > > V1 -> V2: > > - Drop chip->busy_timeout_ms. TPM2 durations and the TPM2_RC_RETRY > > budget now come from chip->duration, which drivers adjust through > > ->update_durations() as TPM 1.x does. > > - Map TPM2_CC_SELF_TEST and TPM2_CC_VERIFY_SIGNATURE to TPM_LONG with > > floors of 3s and 30s since their durations do not fit SHORT, MEDIUM, > > LONG durations. > > - Keep the TPM2 defaults for commands sent before tpm2_get_timeouts() > > has run such as the one in tpm2_probe() and keep the 2s retry > > budget for TPM 1.x chips. > > - Keep the first TPM2_RC_RETRY wait at TPM2_DURATION_SHORT instead of > > chip->duration[TPM_SHORT]. > > - Return early from tpm_tis_update_durations() for TPM2 chips, since > > its overrides are for TPM 1.x. > > - Rename from "tpm: Add per-chip timeout for transient unavailability". > > > > v1: > > https://lore.kernel.org/linux-integrity/[email protected]/ > > While the issue does get addressed the patch also makes the code > base worse. What would be more feasible would be to address the > architectural issue. > > We absolutely do not want a new special to tpm_transmit().
I.e. unifying and adding coherency would be what I would emphasize here not shortcircuiting the actual issues and adding special conditions. I think this change is optimizing for being non-distruptive as an optimal goals e.g., by not reconsidering TPM ops etc. and like the bird eye picture. I think this would be a good chance to do something much more long term than this. This is BTW something to look up for with LLM generated changes: LLMs often optimize towards a bug fix type of minimum side-effect change. It is probably good to make this type of reflection when pre-checking any feature patch. I'm not complaining, this isjust something that I just realized. Just another way to look up whether LLM generated result is "good" or "bad" because it is very easy to get a blind eye for this. Br, Jarkko
