Re: [PATCH v3 1/2] tpm: Disable a TPM that stops responding

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Nov 13, 2026 at 07:14:39AM -0800, Breno Leitao wrote:
> On Fri, Nov 13, 2026 at 04:42:20PM +0200, Jarkko Sakkinen wrote:
> > On Fri, Nov 13, 2026 at 02:38:58AM -0800, Breno Leitao wrote:
> > > @@ -40,6 +40,11 @@ module_param_named(suspend_pcr, tpm_suspend_pcr, uint, 0644);
> > >  MODULE_PARM_DESC(suspend_pcr,
> > >  		 "PCR to use for dummy writes to facilitate flush on suspend.");
> > >  
> > > +static unsigned int tpm_max_missed_responses = 60;
> > 
> > This looks good but I started to think this number. I guess it is high
> > because there's never reset-to-zero for chip->nr_missed_responses.
> >
> > I think three or four trials at most should be enough, and when there 
> > is a successful transmission chip->nr_missed_responses should reset.
> 
> It does reset. Any command that gets an answer, whatever its return
> code, sets the count back to zero:
> 
> 	if (ret >= 0) {
> 		chip->nr_missed_responses = 0;
> 
> so the TPM is only disabled after 60 timeouts with no answer in between.

Oops, sorry had a blind spot.

This made me thinking that it is unlikely that there would be a sequence
of -ETIME's and then things started suddenly working. It is not a likely
world scenario.

So really TPM_CHIP_FLAG_MISSED_RESPONSE could be the counter: it is set
when -ETIME happens, allowing a single -ETIME failure but not a sequence
of them.

Sorry, this simply did not cross mind earlier.

Second open question: do we want to disable or move into firmware
upgrade mode?

Stefan, could you review this patch set from this angle? I don't feel
I have enough expertise on this topic.


>     Some TPMs stop responding at runtime, hours to months after they
>     passed probe. The first sign is usually "invalid TPM_STS.x 0xff",
>     and from then on every command fails only after the transport
>     timeout. A TPM that is already dead at boot fails tpm2_probe() and
>     never registers, which is not affected by this patchset/feature.

This is much better. It is as accurate as possible, which is good
enough.

> 
> Thanks,
> --breno

Br, Jarkko