On Tue, Jun 20, 2017 at 11:32:41PM +0200, Jarkko Sakkinen wrote:
On Tue, Jun 20, 2017 at 05:25:57PM -0400, Stefan Berger wrote:It's fixed in the 'readpubek' branch. If that is the only concern, can
On 06/20/2017 04:55 PM, Jarkko Sakkinen wrote:Ah. Thanks. I'll fix that.
On Tue, Jun 20, 2017 at 01:31:52PM -0600, Jason Gunthorpe wrote:Doesn't work. The startup_type is be16, but you are appending a u32 now for
On Tue, Jun 20, 2017 at 08:13:34PM +0200, Jarkko Sakkinen wrote:I agree.
Consolidated all the "manual" TPM startup code to a single functionMakes sense to me
in order to make code flows a bit cleaner and migrate to tpm_buf.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
drivers/char/tpm/tpm-interface.c | 67 +++++++++++++++++++++++++---------------
drivers/char/tpm/tpm.h | 6 +---
drivers/char/tpm/tpm2-cmd.c | 32 +------------------
3 files changed, 44 insertions(+), 61 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.cWe should really have a tpm1.h and tpm2.h that has all these various
index d2b4df6d9894..fbef47d8bd06 100644
@@ -540,6 +540,47 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
+#define TPM_ORD_STARTUP 153
+#define TPM_ST_CLEAR 1
constants and things instead of open coding them randomly all over..
Is this patch acceptable to be applied?
Stefan, can you peer test this with a TPM emulator? For convenient testing
I created 'readpubek' branch that includes also my readpubek bug fixes.
Seeing that the module loads and you can output pubek sysfs attribute is
sufficient for seeing that all the three patches work.
both TPM1.2 and TPM2.
+ tpm_buf_append_u32(&buf, TPM_ST_CLEAR);
you test that branch and see if it is OK so that we don't need a new
cycle for the patch set?