From: Alexander Steffen <Alexander.Steffen@infineon.com>
To: Stephen Boyd <swboyd@chromium.org>,
Peter Huewe <peterhuewe@gmx.de>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Andrey Pronin <apronin@chromium.org>,
<linux-kernel@vger.kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
<linux-integrity@vger.kernel.org>,
Duncan Laurie <dlaurie@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
Dmitry Torokhov <dtor@chromium.org>
Subject: Re: [PATCH v2 3/6] tpm_tis_spi: add max xfer size
Date: Wed, 17 Jul 2019 10:07:11 +0200 [thread overview]
Message-ID: <7daa4875-eddd-518d-2622-754ccfbfc421@infineon.com> (raw)
In-Reply-To: <20190716224518.62556-4-swboyd@chromium.org>
On 17.07.2019 00:45, Stephen Boyd wrote:
> From: Andrey Pronin <apronin@chromium.org>
>
> Reject burstcounts larger than 64 bytes reported by tpm.
This is not the correct thing to do here. To quote the specification:
"burstCount is defined as the number of bytes that can be written to or
read from the data FIFO by the software without incurring a wait state."
(https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client_Platform_TPM_Profile_PTP_2.0_r1.03_v22.pdf
Page 84)
If the FIFO contains 1k of data, it is completely valid for the TPM to
report that as its burstCount, there is no need to arbitrarily limit it.
Also, burstCount is a property of the high-level TIS protocol, that
should not really care whether the low-level transfers are done via LPC
or SPI (or I2C). Since tpm_tis_spi can only transfer 64 bytes at a time,
it is its job to split larger transfers (which it does perfectly fine).
This also has the advantage that burstCount needs only to be read once,
and then we can do 16 SPI transfers in a row to read that 1k of data.
With your change, it will read 64 bytes, then read burstCount again,
before reading the next 64 bytes and so on. This unnecessarily limits
performance.
Maybe you can describe the problem you're trying to solve in more
detail, so that a better solution can be found, since this is clearly
something not intended by the spec.
Alexander
next prev parent reply other threads:[~2019-07-17 8:07 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-16 22:45 [PATCH v2 0/6] tpm: Add driver for cr50 Stephen Boyd
2019-07-16 22:45 ` [PATCH v2 1/6] hwrng: core: Freeze khwrng thread during suspend Stephen Boyd
2019-07-17 1:43 ` Herbert Xu
2019-07-17 16:36 ` Stephen Boyd
2019-07-17 11:39 ` Jason Gunthorpe
2019-07-17 16:42 ` Stephen Boyd
2019-07-17 16:50 ` Jason Gunthorpe
2019-07-17 17:03 ` Stephen Boyd
2019-08-02 22:50 ` Stephen Boyd
2019-08-16 15:56 ` Alexander Steffen
2019-08-16 23:55 ` Jarkko Sakkinen
2019-08-02 20:22 ` Jarkko Sakkinen
2019-08-02 23:18 ` Stephen Boyd
2019-07-16 22:45 ` [PATCH v2 2/6] tpm_tis_core: add optional max xfer size check Stephen Boyd
2019-07-16 22:45 ` [PATCH v2 3/6] tpm_tis_spi: add max xfer size Stephen Boyd
2019-07-17 8:07 ` Alexander Steffen [this message]
2019-07-17 18:19 ` Stephen Boyd
2019-07-16 22:45 ` [PATCH v2 4/6] dt-bindings: tpm: document properties for cr50 Stephen Boyd
2019-07-16 22:45 ` [PATCH v2 5/6] tpm: add driver for cr50 on SPI Stephen Boyd
2019-07-17 12:00 ` Alexander Steffen
2019-07-17 12:25 ` Jason Gunthorpe
2019-07-17 16:49 ` Stephen Boyd
2019-07-17 16:56 ` Jason Gunthorpe
2019-07-17 17:05 ` Stephen Boyd
2019-07-17 17:12 ` Jason Gunthorpe
2019-07-17 17:22 ` Stephen Boyd
2019-07-17 17:25 ` Jason Gunthorpe
2019-07-17 18:21 ` Stephen Boyd
2019-07-17 18:30 ` Guenter Roeck
2019-07-17 18:36 ` Jason Gunthorpe
2019-07-17 19:57 ` Stephen Boyd
2019-07-17 21:38 ` Stephen Boyd
2019-07-17 22:17 ` Stephen Boyd
2019-07-18 16:47 ` Alexander Steffen
2019-07-18 18:11 ` Stephen Boyd
2019-07-19 7:53 ` Alexander Steffen
2019-08-01 16:02 ` Stephen Boyd
2019-08-02 15:21 ` Jarkko Sakkinen
2019-08-02 18:03 ` Stephen Boyd
2019-08-02 19:43 ` Jarkko Sakkinen
2019-07-18 16:47 ` Alexander Steffen
2019-07-18 18:07 ` Stephen Boyd
2019-07-19 7:51 ` Alexander Steffen
2019-08-02 20:43 ` Jarkko Sakkinen
2019-08-02 22:32 ` Stephen Boyd
2019-08-02 20:41 ` Jarkko Sakkinen
2019-07-16 22:45 ` [PATCH v2 6/6] tpm: Add driver for cr50 on I2C Stephen Boyd
2019-07-17 15:19 ` Alexander Steffen
2019-08-05 23:52 ` Stephen Boyd
2019-08-02 20:44 ` Jarkko Sakkinen
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=7daa4875-eddd-518d-2622-754ccfbfc421@infineon.com \
--to=alexander.steffen@infineon.com \
--cc=apronin@chromium.org \
--cc=arnd@arndb.de \
--cc=dlaurie@chromium.org \
--cc=dtor@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=swboyd@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).