Messages in this thread | | | Subject | Re: [PATCH] tpm/tpm_tis: Fix variable reset during IRQ probing | From | Tianjia Zhang <> | Date | Wed, 20 Jan 2021 12:03:49 +0800 |
| |
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
| |