Hi,
On 7/26/22 12:17, Krzysztof Kozlowski wrote:
On 24/07/2022 00:49, Maximilian Luz wrote:
Add bindings for the Qualcomm Trusted Execution Environment (TrEE) UEFI
Secure application (uefisecapp) client.
Signed-off-by: Maximilian Luz <luzmaximilian@xxxxxxxxx>
---
.../firmware/qcom,tee-uefisecapp.yaml | 38 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/qcom,tee-uefisecapp.yaml
diff --git a/Documentation/devicetree/bindings/firmware/qcom,tee-uefisecapp.yaml b/Documentation/devicetree/bindings/firmware/qcom,tee-uefisecapp.yaml
new file mode 100644
index 000000000000..9e5de1005d5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,tee-uefisecapp.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml#
Does not look like you tested the bindings. Please run `make
dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Sorry, first time submitting a schema. Already saw the warning of Rob's
bot and Will fix this in v2.
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Trusted Execution Environment UEFI Secure Application
+
+maintainers:
+ - Maximilian Luz <luzmaximilian@xxxxxxxxx>
+
+description: |
+ Various Qualcomm SoCs do not allow direct access to UEFI variables. Instead,
+ these need to be accessed via the UEFI Secure Application (uefisecapp),
+ residing in the Trusted Execution Environment (TrEE). These bindings mark the
+ presence of uefisecapp and allow the respective client driver to load and
+ install efivar operations, providing the kernel with access to UEFI
+ variables.
+
+properties:
+ compatible:
+ const: qcom,tee-uefisecapp
Isn't this SoC-specific device? Generic compatibles are usually not
expected.
This is essentially software (kernel driver) talking to software (in the
TrustZone), so I don't expect there to be anything SoC specific about it.
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ firmware {
+ scm {
+ compatible = "qcom,scm-sc8180x", "qcom,scm";
+ };
+ tee-uefisecapp {
+ compatible = "qcom,tee-uefisecapp";
You did not model here any dependency on SCM. This is not full
description of the firmware/hardware
How would I do that? A lot of other stuff also depends on SCM being
present (e.g. qcom_q6v5_pas for loading mdt files) and I don't see them
declare this in the device tree. As far as I can tell, SCM is pretty
much expected to be there at all times (i.e. can't be unloaded) and
drivers check for it when probing via qcom_scm_is_available(),
deferring probe if not.
Don't take this as an excuse as in "I want to leave that out", it's just
that I don't know how one would declare such a dependency explicitly. If
you can tell me how to fix it, I'll include that for v2.
Regards,
Max
