tpm_tis: Quiesce interrupts before registering a handler

[kbowling]

Summary

The current interrupt path uses the IRQ resource value directly as the
LPC SIRQ selector in TPM_INT_VECTOR and already restricts it to 1 through
15. This is a driver limitation: a parent interrupt number need not equal
an LPC SIRQ channel, and SPI TPMs can use a separate parallel interrupt.

On the reported system with ACPI IRQ 45, the existing range check runs
after handler registration and returns before disabling firmware interrupt
delivery. This can leave a polling device with a handler on an asserted
source.

Disable and verify interrupt delivery before registering a handler or
starting common TPM services. Preserve the existing range policy, using
polling without registering a handler for routes rejected by that check,
and release their IRQ resources. Keep a failed setup's potentially stale
output cookie out of the device state; the interrupt framework may
already have removed that handler.

Cancel timed-out locality requests in the shared request helper, covering
both interrupt programming and commands. Permit attach after a locality
timeout if the enable register proves delivery is already off, allowing
later command recovery. If delivery remains enabled and cannot be
quiesced, fail attach instead of exposing a device node for possible later
recovery. Report this as a quiesce failure since locality acquisition as
well as register programming can fail.

On detach, publish dying and serialize with commands before quiescing TPM
interrupt delivery. Do this for polling devices too, since firmware may
have re-enabled delivery and resume-time quiescing may have failed. Quiesce
before common release destroys the command lock and before removing any
handler. Report hardware quiesce failure while completing software cleanup.

Reported by:    adrian
MFC after:      2 weeks

[adrian]

yup, fixed my setup:

tpmtis0: <Trusted Platform Module 2.0, FIFO mode> iomem 0xfed40000-0xfed44fff irq 45 on acpi0
tpmtis0: cannot use IRQ 45; using polling
adrian@test-3:~ %

[imp]

So I'm confused, why would the parent IRQ numbering matter here? Maybe explain that in the commit message since ISA is the only place that matters. ACPI interrupt isn't sufficiently specific, I guess.

sys/dev/tpm/tpm_tis_core.c

161

So I'm confused here...

[kbowling]

In D59645#1368697, @imp wrote:

So I'm confused, why would the parent IRQ numbering matter here? Maybe explain that in the commit message since ISA is the only place that matters. ACPI interrupt isn't sufficiently specific, I guess.

The parent IRQ number need not equal an LPC SIRQ selector. The current driver assumes that mapping when programming TPM_INT_VECTOR and already rejects values outside 1–15.

The bug here is that the existing "storm" guard registered the handler before rejecting the IRQ, and returned before disabling firmware interrupt delivery. This change preserves the existing polling fallback, disables delivery first, and avoids registering a handler for a route we cannot currently configure. Supporting other interrupt routes needs separate handling. I’ll clarify the summary and comment.

[kbowling]

Clarify current IRQ limit

[imp]

Thanks!

[adrian]

For reference - this is attached to a 10th generation intel cpu (i5-10500)

CPU: Intel(R) Core(TM) i5-10500 CPU @ 3.10GHz (3100.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0xa0653  Family=0x6  Model=0xa5  Stepping=3