On 5/18/2022 4:21 PM, James Bottomley wrote:
> Actually, this is nothing to do with the TIMEOUTS_A-D: those are the
> maximum times before a command should complete.  This is the minimum
> time we should wait between pokes of the TPM to see if it is ready.
> Usually the use case is:
> 
> while (read device status gives not ready)
>     tpm_msleep(something)
> 
> The tpm_msleep gives up CPU control (to prevent huge amounts of busy
> waiting) but before 424eaf910c32 ("tpm: reduce polling time to usecs
> for even finer granularity") we would sleep for an entire tick (time
> taken to make the process runnable) before the next poll, and since
> most TPM commands don't return immediately, that was a gate on how fast
> you could do simple TPM operations (like PCR extend).
> 
> As far as I know, no TCG spec gives any details of the minimum wait
> time between poll cycles, so this is really something the manufacturer
> has to tell us.
> 
> Just for completeness, my soak test did run to completion, but my TPM
> has since failed and dropped off the bus, so simply reverting this
> patch (5ef924d9e2e8) isn't sufficient to fully fix my problem.

[FYI]

The TPM vendors explained that polling interrupts TPM command
processing. This will make commands take longer.

They recommend adaptive sleep time based on (at least) the
command.  E.g., getcapability, pcrread, ... are fast so a short
sleep is appropriate.  create, createprimary are slow so
a longer sleep will have better performance.