Re: [PATCH 1/2] tpm: Add per-chip timeout for transient unavailability

[Surendran Kanagaraj]

On Fri, Sep 25, 2026, Breno Leitao wrote:
> On Wed, Sep 23, 2026 at 02:28:33PM +0000, Surendran Kanagaraj wrote:
> > Devices that have different timeout requirements than the TPM2 spec
>
> Can you help us understand why this device doesn't follow the spec,
> and why the quirk belongs in the kernel rather than being fixed in
> the TPM2 itself?
>
> Is NitroTPM a virtual TPM? If so, could the virtualization software
> be fixed instead to follow the spec?

Thanks for taking time to review my patches. Yes, its a vTPM. We are
also working on shortening the window on our side but its really hard
to keep it under the budget for all the cases. I also came across
a similar implementation in tpm_crb_ffa which retries a busy TPM based
on module param busy_timeout_ms. Should we adapt this param to crb in
general?

> > +	if (chip->busy_timeout_ms > max_delay_msec)
> > +		max_delay_msec = chip->busy_timeout_ms;
>
> nit: this could use max() instead:
>         max_delay_msec = max(chip->busy_timeout_ms, max_delay_msec).

Agreed, will change.

> Also, should there be an upper bound?

The value only comes from a constant in the driver So I didnt add one. I
can add a upper bound.

> What about something like this instead?
>
>       return msecs_to_jiffies(max_t(unsigned long, duration,
>                                     chip->busy_timeout_ms));

Yes that reads better.

Thanks,
Surendran