tpm_crb: Add support for CRB devices based on Pluton
authorMatthew Garrett <mjg59@srcf.ucam.org>
Sat, 31 Dec 2022 09:14:32 +0000 (01:14 -0800)
committerJarkko Sakkinen <jarkko@kernel.org>
Mon, 13 Feb 2023 08:10:52 +0000 (10:10 +0200)
commit4d2732882703791ea4b670df433f88fc4b40a5cb
treeb4bd475f9aff89592da0b3f50c21832ede7dca6a
parent0f5d4a0b995faa6537c4de79973817a4f8da206a
tpm_crb: Add support for CRB devices based on Pluton

Pluton is an integrated security processor present in some recent Ryzen
parts. If it's enabled, it presents two devices - an MSFT0101 ACPI device
that's broadly an implementation of a Command Response Buffer TPM2, and an
MSFT0200 ACPI device whose functionality I haven't examined in detail yet.
This patch only attempts to add support for the TPM device.

There's a few things that need to be handled here. The first is that the
TPM2 ACPI table uses a previously undefined start method identifier. The
table format appears to include 16 bytes of startup data, which corresponds
to one 64-bit address for a start message and one 64-bit address for a
completion response. The second is that the ACPI tables on the Thinkpad Z13
I'm testing this on don't define any memory windows in _CRS (or, more
accurately, there are two empty memory windows). This check doesn't seem
strictly necessary, so I've skipped that.

Finally, it seems like chip needs to be explicitly asked to transition into
ready status on every command. Failing to do this means that if two
commands are sent in succession without an idle/ready transition in
between, everything will appear to work fine but the response is simply the
original command. I'm working without any docs here, so I'm not sure if
this is actually the required behaviour or if I'm missing something
somewhere else, but doing this results in the chip working reliably.

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
drivers/char/tpm/tpm_crb.c
include/acpi/actbl3.h