On Mon, Sep 28, 2026 at 07:50:20PM +0000, Surendran Kanagaraj wrote:
> 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?
Module parameter is generally a bad way to resolve anything. I don't
have knowledge actually why busy_timeout_ms needs to be a module in
tpm_crb_ffa and it is not possible to resolve busy_timeout_ms at
run-time.
I think tpm_crb driver should simply patch chip->duration table and
on TPM driver side we should start acquiring duration values by indexing
that table.
E.g., consider:
unsigned int delay_msec = TPM2_DURATION_SHORT;
We want to instead:
unsigned int delay_msec = chip->duration[TPM_SHORT];
I.e instead of adding new fields let's take better advantage of what we
have. I think this issue tells that duration table is underused and
these direct assignments from constants does not scale.
Br, Jarkko
