Re: [PATCH v2 3/4] dt-bindings: firmware: Add Qualcomm QSEECOM interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/30/23 22:05, Rob Herring wrote:
On Fri, Jan 27, 2023 at 07:46:49PM +0100, Maximilian Luz wrote:
Add bindings for the Qualcomm Secure Execution Environment interface
(QSEECOM).

Signed-off-by: Maximilian Luz <luzmaximilian@xxxxxxxxx>
---

Changes in v2:
  - Replaces uefisecapp bindings.
  - Fix various dt-checker complaints.

---
  .../bindings/firmware/qcom,qseecom.yaml       | 49 +++++++++++++++++++
  MAINTAINERS                                   |  1 +
  2 files changed, 50 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml

diff --git a/Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml b/Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml
new file mode 100644
index 000000000000..540a604f81bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/qcom,qseecom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Secure Execution Environment Communication Interface
+
+maintainers:
+  - Maximilian Luz <luzmaximilian@xxxxxxxxx>
+
+description: |
+  QSEECOM provides an interface to Qualcomm's Secure Execution Environment
+  (SEE) running in the Trust Zone via SCM calls. In particular, it allows

SCM is SMCCC or something else?

It's whatever qcom-scm.c uses. I'm not too familiar with the specifics,
so maybe someone else can answer this better.

+  communication with secure applications running therein.
+
+  Applications running in this environment can, for example, include
+  'uefisecapp', which is required for accessing UEFI variables on certain
+  systems as these cannot be accessed directly.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - qcom,qseecom-sc8280xp
+      - const: qcom,qseecom
+
+  qcom,scm:
+    $ref: '/schemas/types.yaml#/definitions/phandle'
+    description:
+      A phandle pointing to the QCOM SCM device (see ./qcom,scm.yaml).
+
+required:
+  - compatible
+  - qcom,scm
+
+additionalProperties: false
+
+examples:
+  - |
+    firmware {
+        scm {
+            compatible = "qcom,scm-sc8280xp", "qcom,scm";
+        };
+        qseecom {
+            compatible = "qcom,qseecom-sc8280xp", "qcom,qseecom";
+            qcom,scm = <&scm>;

Why do you need this in DT? If you already know you have a firmware
interface (via "qcom,scm"), then query the firmware to see if the SEE is
there.

Unfortunately I don't know of any way to query this, but please let me
know if you do.

As I've briefly mentioned in the cover letter: There are two interfaces
to manage secure apps. QSEECOM (on older and current-gen laptop devices)
and scminvoke (on newer and some current-gen mobile devices if I
understood right). ACPI also uses a separate device for this
(QCOM0476), so it seemed like the best option to follow that.

Ideally, scminvoke would be preferred since that can be integrated as
TEE driver, but I've been told that on platforms where apps (like
uefisecapp) are loaded via QSEECOM by firmware, we can only use QSEECOM
to communicate with those.

Regards,
Max




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux