On Fri Apr 10 20, Jason Gunthorpe wrote:
On Thu, Apr 09, 2020 at 11:10:44PM +0200, Hans de Goede wrote:
Since commit dda8b2af395b ("tpm: Revert "tpm_tis_core: Set
TPM_CHIP_FLAG_IRQ before probing for interrupts"") we no longer set
the TPM_CHIP_FLAG_IRQ ever.
This all used to work..
IIRC this goes all the way back to 570a36097f30 ("tpm: drop 'irq' from struct tpm_vendor_specific")
when the flag was added. There was never anything initially setting it in the tpm_tis code.
There were checks added, but the only place it got set was where it did the interrupt test in
tpm_tis_send, and it can only get down to that code if the flag is set. Stefan's patch was enabling
the flag, but with the flag enabled some systems were seeing interrupt storms. I believe it has
been seen with both the t490 and an internal system that Dan Williams was working on at Intel.
Without access to hw seeing the problem the decision was to revert Stefan's patches while
we try to figure out the issues.
So the whole IRQ probing code is not useful, worse we rely on the
IRQ-test path of tpm_tis_send() to call disable_interrupts() if
interrupts do not work, but that path never gets entered because we
never set the TPM_CHIP_FLAG_IRQ.
The IRQ probing code should be deleted.
On some systems, e.g. the Lenovo X1 8th gen, the interrupt we try
to use and never free creates an interrupt storm followed by
an "irq XX: nobody cared" oops.
Is this related to probing?
Jason
