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
