On Tue Dec 17 19, Jerry Snitselaar wrote:
On Tue Dec 17 19, Jarkko Sakkinen wrote:
On Mon, 2019-12-16 at 18:14 -0800, Dan Williams wrote:
On Mon, Dec 16, 2019 at 6:00 PM Jerry Snitselaar jsnitsel@redhat.com wrote:
On Mon Dec 16 19, Dan Williams wrote:
On Mon, Dec 16, 2019 at 4:59 PM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
On Wed, 2019-12-11 at 16:54 -0700, Jerry Snitselaar wrote: > Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when > issuing commands to the tpm during initialization, just reserve the > chip after wait_startup, and release it when we are ready to call > tpm_chip_register. > > Cc: Christian Bundy christianbundy@fraction.io > Cc: Dan Williams dan.j.williams@intel.com > Cc: Peter Huewe peterhuewe@gmx.de > Cc: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com > Cc: Jason Gunthorpe jgg@ziepe.ca > Cc: Stefan Berger stefanb@linux.vnet.ibm.com > Cc: stable@vger.kernel.org > Cc: linux-integrity@vger.kernel.org > Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") > Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's") > Signed-off-by: Jerry Snitselaar jsnitsel@redhat.com
I pushed to my master with minor tweaks and added my tags.
Please check before I put it to linux-next.
I don't see it yet here:
http://git.infradead.org/users/jjs/linux-tpmdd.git/shortlog/refs/heads/maste...
However, I wanted to make sure you captured that this does *not* fix the interrupt issue. I.e. make sure you remove the "Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")" tag.
With that said, are you going to include the revert of:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Dan, with the above reverted do you still get the screaming interrupt?
Yes, the screaming interrupt goes away, although it is replaced by these messages when the driver starts:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
If the choice is "error message + polled-mode" vs "pinning a cpu with interrupts" I'd accept the former, but wanted Jarkko with his maintainer hat to weigh in.
Is there a simple sanity check I can run to see if the TPM is still operational in this state?
What about T490S?
/Jarkko
Hi Jarkko, I'm waiting to hear back from the t490s user, but I imagine it still has the problem as well.
It appears he is out of the office until January, so I doubt I will hear anything back until then.
Christian, were you able to try this patch and verify it still resolves the issue you were having with the kernel failing to get the timeouts and durations from the tpm?
Thanks, Jerry