i2c/tpm: Ignore 0xFF bytes for status and burstCount
commita69ac7861b03e438e62c57992c30d9c42996c56b
authorJulius Werner <jwerner@chromium.org>
Thu, 1 Dec 2016 01:46:17 +0000 (30 17:46 -0800)
committerPatrick Georgi <pgeorgi@google.com>
Tue, 3 Jan 2017 21:13:19 +0000 (3 22:13 +0100)
treea6080e8a43a2fdd1d61ccf35ce6b07391fa3a5ea
parentb431a51086f89e74aa681b61744bc312255b6cb4
i2c/tpm: Ignore 0xFF bytes for status and burstCount

We've found that the SLB9645 TPM sometimes seems to randomly start
returning 0xFF bytes for all requests. The exact cause is yet unknown,
but we should try to write our TIS code such that it avoids bad
interactions with this kind of response (e.g. any wait_for_status()
immediately succeeds because all "status bits" are set in the response).
At least for status and burstCount readings we can say for sure that the
value is nonsensical and we're already reading those in a loop until we
get valid results anyway, so let's add code to explicitly discount 0xFF
bytes.

BRANCH=oak
BUG=chrome-os-partner:55764
TEST=None

Change-Id: I934d42c36d6847a22a185795cea49d282fa113d9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420470
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://review.coreboot.org/18006
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
src/drivers/i2c/tpm/tpm.c