On 1/15/21 5:23 PM, Jarkko Sakkinen wrote:
On Thu, Jan 14, 2021 at 12:12:16PM +0800, Tianjia Zhang wrote:
On 1/14/21 10:51 AM, Jarkko Sakkinen wrote:
On Wed, Jan 13, 2021 at 08:00:21PM +0800, Tianjia Zhang wrote:
In tpm_tis_core_init(), tpm2_probe() will be called first, this
function will eventually call tpm_tis_send(), and then
tpm_tis_probe_irq_single() will detect whether the interrupt is
normal, mainly the installation interrupted, set `priv->irq_tested`
to false. The logic will eventually be executed to tpm_tis_send()
to trigger an interrupt.
There is currently such a scenario, which will cause the IRQ probe
code to never be executed, so that the TPM device is in polling
mode: after setting irq_tested to false, an interrupt occurs
between entering the ttpm_tis_send() function, and the interrupt
will be first set irq_tested to true will cause the IRQ probe code
to never be executed.
Can you describe the scenario more detail?
The problematic scenario we encountered is like this. The following figure
shows the execution flow of tpm_tis_core_init(). An interrupt occurred
before the IRQ probe. This interrupt was caused by tpm2_probe(), but it was
triggered before the IRQ probe was executed, and the interrupt handler would
set irq_tested to true, so the IRQ probe code can never execute, that is,
the code marked 2 in the figure will never happen.
TPM_INT_ENABLE is cleared on reset [*].
[*] Section 5.9.1
https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
/Jarkko
Hi,
I got it, this seems to be a firmware issue. Thanks for your reply.
Best regards,
Tianjia
