From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-integrity@vger.kernel.org,
Jerry Snitselaar <jsnitsel@redhat.com>,
Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: More interrupt problems with TIS TPM
Date: Wed, 30 Sep 2020 05:14:27 +0300 [thread overview]
Message-ID: <20200930021427.GE808399@linux.intel.com> (raw)
In-Reply-To: <ea07fe04f61fe1ad19060f600ec219679c7bae2d.camel@HansenPartnership.com>
On Mon, Sep 28, 2020 at 05:52:43PM -0700, James Bottomley wrote:
> I've got hold of an infineon TIS TPM which actually has a working
> interrupt. I find even with the other fix I still need the patch below
> to get the interrupt to fire because without it nothing ever sets
> TPM_CHIP_FLAG_IRQ which means the interrupt test code is never
> executed.
>
> Finally with all this probing fixed, I'm seeing interrupt storms. The
> way this TPM seems to work is that if you allow it to send command
> ready interrupts, it will send them any time it can accept a command.
> The problem is if you clear the interrupt and it can accept a command,
> it will send another command ready interrupt ... hence the storm since
> the TPM is pretty much always in the command ready state. The only way
> to mitigate this seems to be *only* to enable the command ready
> interrupt when you're preparing to wait for the TPM to become ready.
> i.e. these interrupts have to be treated as one shot enable, so the
> interrupt routine has to mask the command ready interrupt before doing
> a TPM_EOI in our way of doing things. There seems to be support for
> this in the TIS spec around line 1135 where it advises us to keep all
> interrupts masked until polling says we have to wait for a particular
> state.
>
> James
OK, this makes a lot of sense. I'll go through the patch set that you
posted. Thank you.
>
> ---
>
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index 6b884badabe7..1578d158416c 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -804,6 +810,7 @@ static int tpm_tis_probe_irq_single(struct tpm_chip *chip, u32 intmask,
> return rc;
>
> priv->irq_tested = false;
> + chip->flags |= TPM_CHIP_FLAG_IRQ;
>
> /* Generate an interrupt by having the core call through to
> * tpm_tis_send
>
>
/Jarkko
prev parent reply other threads:[~2020-09-30 2:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 0:52 More interrupt problems with TIS TPM James Bottomley
2020-09-30 2:14 ` Jarkko Sakkinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200930021427.GE808399@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jgg@ziepe.ca \
--cc=jsnitsel@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=peterhuewe@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.