On 11/12/19 3:17 PM, Jerry Snitselaar wrote:
On Tue Nov 12 19, Jarkko Sakkinen wrote:
On Mon, Nov 11, 2019 at 08:36:37PM -0700, Jerry Snitselaar wrote:
Question about 1ea32c83c699 ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ
before probing for interrupts"). Doesn't tpm_tis_send set this flag,
and setting it here in tpm_tis_core_init short circuits what
tpm_tis_send was doing before? There is a bug report of an interrupt
storm from a tpm on a t490s laptop with the Fedora 31 kernel (5.3),
and I'm wondering if this change could cause that. Before they got the
warning about interrupts not working, and using polling instead.
Looks like it. Stefan?
/Jarkko
Stefan is right about the condition check at the beginning of
tpm_tis_send.
if (!(chip->flags & TPM_CHIP_FLAG_IRQ) || priv->irq_tested)
return tpm_tis_send_main(chip, buf, len);
Before his change it would've gone straight to calling
tpm_tis_send_main instead of jumping down and doing the irq test, due
to the flag not being set. With his change it should now skip this
tpm_tis_send_main call when tpm_tis_gen_interrupt is called, and then
after that time through tpm_tis_send priv->irq_tested will be set, and
the flag should be set as to whether or not irqs were working.
I should hopefully have access to a t490s in a few days so I can look
at it,
and try to figure out what is happening.
I hope the t490s is an outlier. Give the patch I just posted a try.
Stefan
