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.
IRQ
tpm_tis_core_init()
tpm2_probe()
tpm_tis_send() -----------+
|
tpm_tis_probe_irq_single() |
|
devm_request_irq() | 1
priv->irq_tested = false |
tpm_tis_gen_interrupt() |
|
tpm_tis_send() |
irq_tested = true |
<------------------+
if (priv->irq_tested)
return tpm_tis_send_main()
/* probe IRQ */
tpm_tis_send_main() --------+
| 2
chip->flags |= FLAG_IRQ <-------+
priv->irq_tested = true
Best regards,
Tianjia
