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

[Maximilian Luz]

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