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. /Jarkko
