On Tue, Apr 09, 2019 at 04:18:29PM -0500, Rob Herring wrote:
On Tue, Apr 9, 2019 at 1:50 PM Sasha Levin <sashal@xxxxxxxxxx> wrote:
The parameters are similar to the ones used by IBM's vTPM and the
various I2C tpm drivers.
Bindings describe h/w (or firmware interfaces in this case), not drivers.
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
.../bindings/security/tpm/tpm_ftpm_tee.txt | 13 +++++++++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt b/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt
new file mode 100644
index 000000000000..20fca67a56c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt
@@ -0,0 +1,13 @@
+Required properties:
+- compatible: should be "microsoft,ftpm"
+- linux,sml-base: 64-bit base address of the reserved memory allocated
+ for the firmware event log
+- linux,sml-size: size of the memory allocated for the firmware event log
Firmware is defining linux specific properties? What if I want to run
BSD? We should use 'reg' here instead.
This is based on already existing code that defines these names, see
tpm_read_log_of() in drivers/char/tpm/eventlog/of.c .
These properties were described similarily by other interfaces (see
Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt or
Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt for example).
We could rename them all if you'd like, I was just trying to follow the
existing code.
What memory is used here? This should be under /reserved-memory if it
is part of "main" memory.
That's my understanding, yes.
Really, I'd prefer to not see this in DT at all. Make the firmware
discoverable. Why repeat the mistakes of non-discoverable h/w in s/w
interfaces? OP-Tee at least has defined a mechanism to enumerate TEE
functions IIRC.
Sadly the firmware already exists as-is on live hardware, there is a
paper describing it back from 2016 and we're stuck having to support
that.
--
Thanks,
Sasha
