From: Doug Anderson <dianders@chromium.org>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
Andrey Pronin <apronin@chromium.org>,
Stephen Boyd <swboyd@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-integrity@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tpm_tis_spi: Don't send anything during flow control
Date: Thu, 4 Jun 2020 06:48:58 -0700 [thread overview]
Message-ID: <CAD=FV=Vgjs4gALALWYVLEYfbFtXi69FrVYziJ9x=YA5RjrV1ww@mail.gmail.com> (raw)
In-Reply-To: <20200604094012.GA8989@linux.intel.com>
Hi,
On Thu, Jun 4, 2020 at 2:40 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Mon, Jun 01, 2020 at 03:54:03PM -0700, Doug Anderson wrote:
> > Does that answer your question, or were you worried about us needing
> > to init iobuf[0] to 0 in some other case?
> >
> > -Doug
>
> No, but it should be treated as a bug fix for CR50 implementation i.e.
> for 797c0113c9a481d4554988d70b5b52fae657262f, or is there some reason
> why it shouldn't?
As talked about in the commit message, I think this is a slight
cleanup for non-Cr50 too. Specifically if we end up running through
the TPM_RETRY loop a second time we weren't re-initting "phy->iobuf[0]
= 0;" That means that the 2nd time through the loop we were actually
sending the TPM back the byte that the TPM sent us the first time
through the loop.
Presumably this doesn't matter much, but it still feels nicer not to
be sending the TPM's bytes back to it when we're not really supposed
to.
Also, as mentioned in the commit message, I haven't observed this
fixing any problems. I only came up with it from code inspection
while trying to track something else down.
-Doug
next prev parent reply other threads:[~2020-06-04 13:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 22:19 [PATCH] tpm_tis_spi: Don't send anything during flow control Douglas Anderson
2020-05-29 8:33 ` Paul Menzel
2020-05-29 15:37 ` Doug Anderson
2020-06-01 1:47 ` Jarkko Sakkinen
2020-06-01 22:54 ` Doug Anderson
2020-06-04 9:40 ` Jarkko Sakkinen
2020-06-04 13:48 ` Doug Anderson [this message]
2020-06-16 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='CAD=FV=Vgjs4gALALWYVLEYfbFtXi69FrVYziJ9x=YA5RjrV1ww@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=apronin@chromium.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.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).