Le 14/02/18 à 12:44, Jarkko Sakkinen a écrit :
On Fri, Feb 09, 2018 at 11:53:55AM +0100, Laurent Bigonville wrote:
I don't remember if I replied to this, re-posting to be sure:
Le 03/01/18 à 01:33, Jerry Snitselaar a écrit :
Hi Laurent,
Can you try the following debug patch (earlier idea of adding a sleep to
allow
tpm to complete state transition):
--8<--
diff --git a/drivers/char/tpm/tpm_tis_core.c
b/drivers/char/tpm/tpm_tis_core.c
index fdde971bc810..6a9325b02059 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip,
int l)
struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY);
+ tpm_msleep(200);
}
static int request_locality(struct tpm_chip *chip, int l)
I tried the patch and this is working.
Would that be a viable solution?
Kind regards,
Laurent Bigonville
According to the PC client specification in the section 5.5.2.3:
"For commands indicated as short or medium duration (i.e., those that do
not cause key generation), the TPM SHALL respond to an abort within
TIMEOUT_A. For commands indicated as lon g duration or those that cause
key generation, the TPM SHALL respond to a request to abort the command
within TIMEOUT B"
The section 5.5.2.4 describing the access register does not give much
more light to this i.e. what the expected duration maximum is when there
is no command executing.
The duration that that was in your patch seems to work, cannot this be
implemented?
I'm quite surprised I'm the only one impacted by this...
