On 03/14/2018 03:42 PM, Kevin O'Connor wrote:
On Wed, Mar 14, 2018 at 01:42:41PM -0400, Stefan Berger wrote:
Wait for the tpmRegValidSts flag on the TPM_LOC_STATE_x register.
Since it's not quite clear when this flag may become valid, we request access to the interace on locality 0, which must then make it valid.
Signed-off-by: Stefan Berger stefanb@linux.vnet.ibm.com
src/hw/tpm_drivers.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/src/hw/tpm_drivers.c b/src/hw/tpm_drivers.c index ed58bf5..ad97f67 100644 --- a/src/hw/tpm_drivers.c +++ b/src/hw/tpm_drivers.c @@ -374,12 +374,23 @@ static u32 tis_waitrespready(enum tpmDurationType to_t) return rc; }
+#define CRB_STATE_VALID_STS 0b10000000
/* if device is not there, return '0', '1' otherwise */ static u32 crb_probe(void) { if (!CONFIG_TCGBIOS) return 0;
/* request access -- this must cause a valid STS flag */
writeb(CRB_REG(0, CRB_REG_LOC_CTRL), 1);
Would it be possible to do a sanity check with read operations before doing a write operation? The fear is that the device is not present and the write operation corrupts some other device, causes a bus error, or something else undesirable.
Good point. See my other email to the mailing list regarding the valid bit, the specs and the implementation in QEMU. Maybe we have to adapt the QEMU implementation and set the bit to valid upon initialization of the device, I am not sure about this (see the comment before the write). What Stephen suggested was to read this flag and check whether it indicates valid contents of this and other registers before reading them.
Stefan
-Kevin