Patrick Georgi (pgeorgi@google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18006
-gerrit
commit 113317eafa9d8a42292b46623ef9285707503fe8 Author: Julius Werner jwerner@chromium.org Date: Wed Nov 30 17:46:17 2016 -0800
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 --- src/drivers/i2c/tpm/tpm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/drivers/i2c/tpm/tpm.c b/src/drivers/i2c/tpm/tpm.c index 55c25fe..972b17d 100644 --- a/src/drivers/i2c/tpm/tpm.c +++ b/src/drivers/i2c/tpm/tpm.c @@ -291,6 +291,8 @@ static uint8_t tpm_tis_i2c_status(struct tpm_chip *chip) uint8_t buf; if (iic_tpm_read(TPM_STS(chip->vendor.locality), &buf, 1) < 0) return 0; + else if (buf == 0xff) /* Some TPMs sometimes randomly return 0xff. */ + return 0; else return buf; } @@ -316,7 +318,7 @@ static ssize_t get_burstcount(struct tpm_chip *chip) else burstcnt = (buf[2] << 16) + (buf[1] << 8) + buf[0];
- if (burstcnt) + if (burstcnt && burstcnt != 0xffffff) return burstcnt; mdelay(TPM_TIMEOUT); timeout--;