Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client

[Maximilian Luz]

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