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

[Breno Leitao <leitao@debian.org>]

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.

> One thing that bothers me in the commit message is a piece of
> information that is missing: when does it start to return error?
> From the get go?
> 
> I mean based on provided information one could presume that this
> could be also fixed at driver init by doing a few smoke tests
> and don't let it fully ever initialize.
> 
> "A TPM that stops responding fails" is not very locked in scenario.

I cam update the commit. What about something like:

    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.

Thanks,
--breno