On 30/08/2023 15:48, Bartosz Golaszewski wrote: > On Tue, 29 Aug 2023 at 11:30, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: >> >> On 29.08.2023 10:02, Krzysztof Kozlowski wrote: >>> On 28/08/2023 21:25, Bartosz Golaszewski wrote: >>>> Add Device Tree bindings for Qualcomm TEE Shared Memory Brige - a >>>> mechanism that allows sharing memory buffers between trustzone and the >>>> kernel. >>> >>> Subject prefix: >>> dt-bindings: firmware: >>> >>> >>> >>>> >>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >>>> --- >>>> .../bindings/firmware/qcom,shm-bridge.yaml | 36 +++++++++++++++++++ >>>> 1 file changed, 36 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml b/Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml >>>> new file mode 100644 >>>> index 000000000000..f660962b7b86 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,shm-bridge.yaml >>>> @@ -0,0 +1,36 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/firmware/qcom,shm-bridge.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: QCOM Shared Memory Bridge >>>> + >>>> +description: | >>> >>> Do not need '|' unless you need to preserve formatting. >>> >>>> + Qualcomm TEE Shared Memory Bridge allows sharing limited areas of kernel's >>>> + virtual memory with the trustzone in order to avoid mapping the entire RAM. >>>> + >>>> +maintainers: >>>> + - Bjorn Andersson <andersson@xxxxxxxxxx> >>>> + - Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> >>>> + - Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >>>> + >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - enum: >>>> + - qcom,shm-bridge-sa8775p >>>> + - qcom,shm-bridge-sm8150 >>>> + - qcom,shm-bridge-sm8450 >>>> + - const: qcom,shm-bridge >>>> + >>> >>> Looks quite empty... Why this cannot be part of qcom,scm? IOW, why do >>> you need new binding if you do not have any resources here and the block >>> is essentially feature of qcom,scm firmware? >> Since it's "discoverable" (via retval of an scm call), I'd second the >> idea of probing this from within the SCM driver. >> >> Konrad > > Downstream has a bunch of DT switches that we don't support for now > upstream. I disagree about shoehorning this into the SCM driver. It > really is a layer on top of SCM but also SCM is a user of this > interface. Sure, for the driver makes sense, but it does not really explain why DT node is needed. It is not separate hardware. I doubt it is even separate firmware, but part of SCM. Best regards, Krzysztof
