All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Alexander Steffen <Alexander.Steffen@infineon.com>
Cc: nayna@linux.vnet.ibm.com, kgold@linux.vnet.ibm.com,
	linux-integrity@vger.kernel.org
Subject: Re: [RFC][PATCH 3/9] tpm_tis_core: correctly wait for flags to become zero
Date: Thu, 18 Jan 2018 19:59:48 +0200	[thread overview]
Message-ID: <20180118175948.dwyinkqx5bvff44o@linux.intel.com> (raw)
In-Reply-To: <20180118175832.qrxoz6q4nyjkyp3l@linux.intel.com>

On Thu, Jan 18, 2018 at 07:58:32PM +0200, Jarkko Sakkinen wrote:
> On Fri, Dec 08, 2017 at 07:46:52PM +0100, Alexander Steffen wrote:
> > According to TIS/PTP the dataAvail flag and the Expect flag in the STS
> > register contain valid values if and only if the stsValid flag in the same
> > register is set. Currently, the code first waits for the stsValid flag to
> > be set and then looks at the other flags. This causes the STS register to
> > be read twice, so that the stsValid flag might not be set anymore when the
> > other flags are evaluated.
> > 
> > Other parts of the code already check both flags in a single operation
> > within wait_for_tpm_stat. But the current implementation can only check for
> > flags being set to 1, not 0. Therefore, add a parameter to
> > wait_for_tpm_stat that allows to specify the expected value in addition to
> > the selected flags and adapt all callers accordingly.
> > 
> > In addition, this now checks the dataAvail and Expect flags multiple times
> > within the specified timeout, so those flags no longer need to have the
> > expected value right away. This is important for example when sending large
> > amounts of data to the TPM, when the TPM might not process its I/O buffer
> > fast enough for the flags to be set correctly when they are checked for the
> > first time.
> > 
> > Signed-off-by: Alexander Steffen <Alexander.Steffen@infineon.com>
> 
> LGTM
> 
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> 
> /Jarkko

Ugh, was meant for 4/9 :-) Ignore this.

/Jarkko

  reply	other threads:[~2018-01-18 17:59 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 18:46 [RFC][PATCH 0/9] tpm: fix driver so that burstcount can be safely ignored Alexander Steffen
2017-12-08 18:46 ` [RFC][PATCH 1/9] tpm_tis_core: clean up whitespace Alexander Steffen
2018-01-18 17:11   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 2/9] tpm_tis_core: access single TIS registers before doing complex transfers Alexander Steffen
2018-01-18 17:16   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 3/9] tpm_tis_core: correctly wait for flags to become zero Alexander Steffen
2018-01-18 17:49   ` Jarkko Sakkinen
2018-01-18 17:58   ` Jarkko Sakkinen
2018-01-18 17:59     ` Jarkko Sakkinen [this message]
2017-12-08 18:46 ` [RFC][PATCH 4/9] tpm_tis_core: send all data in single operation Alexander Steffen
2017-12-19  9:01   ` Nayna Jain
2018-01-18 18:04   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 5/9] tpm_tis_core: use XDATA_FIFO for transfers if available Alexander Steffen
2018-01-18 18:20   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 6/9] tpm_tis_spi: fix sending wrong data during wait state handling Alexander Steffen
2018-01-18 18:26   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 7/9] tpm_tis_spi: release CS line when wait state handling fails Alexander Steffen
2018-01-18 18:30   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 8/9] tpm_tis_spi: add delay between wait state retries Alexander Steffen
2018-01-11 19:46   ` Mimi Zohar
2018-01-12  8:28     ` Alexander Steffen
2018-01-12 14:53       ` Mimi Zohar
2018-01-15 22:30       ` Mimi Zohar
2018-01-17 17:15         ` Mimi Zohar
2018-01-17 18:58           ` Alexander Steffen
2018-01-18 18:32   ` Jarkko Sakkinen
2017-12-08 18:46 ` [RFC][PATCH 9/9] tpm: ignore burstcount to improve tpm_tis send() performance Alexander Steffen
2017-12-15 12:04 ` [RFC][PATCH 0/9] tpm: fix driver so that burstcount can be safely ignored Jarkko Sakkinen
2017-12-24 20:41   ` Jarkko Sakkinen
2018-01-04 13:11     ` Alexander.Steffen
2018-01-05  6:46       ` Nayna Jain
2018-01-05  7:38         ` Alexander Steffen
2018-01-08 10:50           ` Jarkko Sakkinen
2018-01-08 10:49       ` Jarkko Sakkinen
2017-12-19  8:53 ` Nayna Jain

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=20180118175948.dwyinkqx5bvff44o@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=Alexander.Steffen@infineon.com \
    --cc=kgold@linux.vnet.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=nayna@linux.vnet.ibm.com \
    /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.