From: Alexander Steffen <Alexander.Steffen@infineon.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
<linux-integrity@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] tpm_tis: Use responseRetry to recover from data transfer errors
Date: Wed, 7 Jun 2023 19:14:55 +0200 [thread overview]
Message-ID: <34f01f17-3091-0ce2-f0c3-b0cd25ea61ce@infineon.com> (raw)
In-Reply-To: <CT5VOWDNIK5S.1549VUD23JWWB@suppilovahvero>
On 06.06.23 23:17, Jarkko Sakkinen wrote:
> On Mon Jun 5, 2023 at 8:59 PM EEST, Alexander Steffen wrote:
>> TPM responses may become damaged during transmission, for example due to
>> bit flips on the wire. Instead of aborting when detecting such issues, the
>> responseRetry functionality can be used to make the TPM retransmit its
>> response and receive it again without errors.
>>
>> Signed-off-by: Alexander Steffen <Alexander.Steffen@infineon.com>
>> ---
>> drivers/char/tpm/tpm_tis_core.c | 40 ++++++++++++++++++++++++++-------
>> drivers/char/tpm/tpm_tis_core.h | 1 +
>> 2 files changed, 33 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
>> index 5ddaf24518be..a08768e55803 100644
>> --- a/drivers/char/tpm/tpm_tis_core.c
>> +++ b/drivers/char/tpm/tpm_tis_core.c
>> @@ -345,11 +345,6 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
>> u32 expected;
>> int rc;
>>
>> - if (count < TPM_HEADER_SIZE) {
>> - size = -EIO;
>> - goto out;
>> - }
>> -
>> size = recv_data(chip, buf, TPM_HEADER_SIZE);
>> /* read first 10 bytes, including tag, paramsize, and result */
>> if (size < TPM_HEADER_SIZE) {
>> @@ -382,7 +377,7 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
>> goto out;
>> }
>> status = tpm_tis_status(chip);
>> - if (status & TPM_STS_DATA_AVAIL) { /* retry? */
>> + if (status & TPM_STS_DATA_AVAIL) {
>
> Please remove (no-op).
You mean I shouldn't change the line and leave the comment in? To me it
looked like a very brief TODO comment "should we retry here?", and since
with this change it now actually does retry, I removed it.
>> dev_err(&chip->dev, "Error left over data\n");
>> size = -EIO;
>> goto out;
>> @@ -396,10 +391,39 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
>> }
>>
>> out:
>> - tpm_tis_ready(chip);
>> return size;
>> }
>>
>> +static int tpm_tis_recv_with_retries(struct tpm_chip *chip, u8 *buf, size_t count)
>
> This *substitutes* the curent tpm_tis_recv(), right?
>
> So it *is* tpm_tis_recv(), i.e. no renames thank you :-)
>
>> +{
>> + struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
>> + unsigned int try;
>> + int rc = 0;
>> +
>> + if (count < TPM_HEADER_SIZE) {
>> + rc = -EIO;
>> + goto out;
>> + }
>> +
>> + for (try = 0; try < TPM_RETRY; try++) {
>> + rc = tpm_tis_recv(chip, buf, count);
>
> I would rename single shot tpm_tis_recv() as tpm_tis_try_recv().
>
>> +
>> + if (rc == -EIO) {
>> + /* Data transfer errors, indicated by EIO, can be
>> + * recovered by rereading the response.
>> + */
>> + tpm_tis_write8(priv, TPM_STS(priv->locality),
>> + TPM_STS_RESPONSE_RETRY);
>> + } else {
>> + break;
>> + }
>
> And if this should really be managed inside tpm_tis_try_recv(), and
> then return zero (as the code block consumes the return value).
What exactly should be done in tpm_tis_try_recv()? It could set
TPM_STS_RESPONSE_RETRY, but then it would still need to return an error
code, so that this loop knows whether to call it again or not.
>> + }
>> +
>> +out:
>> + tpm_tis_ready(chip);
>
> Empty line here (nit).
>
>> + return rc;
>> +}
>> +
>> /*
>> * If interrupts are used (signaled by an irq set in the vendor structure)
>> * tpm.c can skip polling for the data to be available as the interrupt is
>> @@ -986,7 +1010,7 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value)
>> static const struct tpm_class_ops tpm_tis = {
>> .flags = TPM_OPS_AUTO_STARTUP,
>> .status = tpm_tis_status,
>> - .recv = tpm_tis_recv,
>> + .recv = tpm_tis_recv_with_retries,
>> .send = tpm_tis_send,
>> .cancel = tpm_tis_ready,
>> .update_timeouts = tpm_tis_update_timeouts,
>> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
>> index e978f457fd4d..8458cd4a84ec 100644
>> --- a/drivers/char/tpm/tpm_tis_core.h
>> +++ b/drivers/char/tpm/tpm_tis_core.h
>> @@ -34,6 +34,7 @@ enum tis_status {
>> TPM_STS_GO = 0x20,
>> TPM_STS_DATA_AVAIL = 0x10,
>> TPM_STS_DATA_EXPECT = 0x08,
>> + TPM_STS_RESPONSE_RETRY = 0x02,
>> TPM_STS_READ_ZERO = 0x23, /* bits that must be zero on read */
>> };
>>
>> --
>> 2.34.1
>
> BR, Jarkko
next prev parent reply other threads:[~2023-06-07 17:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-05 17:59 [PATCH 0/4] Recovery from data transfer errors for tpm_tis Alexander Steffen
2023-06-05 17:59 ` [PATCH v2 1/4] tpm_tis: Explicitly check for error code Alexander Steffen
2023-06-06 21:09 ` Jarkko Sakkinen
2023-06-05 17:59 ` [PATCH v2 2/4] tpm_tis: Move CRC check to generic send routine Alexander Steffen
2023-06-06 21:10 ` Jarkko Sakkinen
2023-06-05 17:59 ` [PATCH v2 3/4] tpm_tis: Use responseRetry to recover from data transfer errors Alexander Steffen
2023-06-06 21:17 ` Jarkko Sakkinen
2023-06-07 17:14 ` Alexander Steffen [this message]
2023-06-08 14:00 ` Jarkko Sakkinen
2023-06-13 17:37 ` Alexander Steffen
2023-06-06 21:18 ` Jarkko Sakkinen
2023-06-05 17:59 ` [PATCH v2 4/4] tpm_tis: Resend command " Alexander Steffen
2023-06-06 21:19 ` 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=34f01f17-3091-0ce2-f0c3-b0cd25ea61ce@infineon.com \
--to=alexander.steffen@infineon.com \
--cc=jarkko@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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