On 30/08/2023 16:39, Bartosz Golaszewski wrote: > On Wed, 30 Aug 2023 at 16:31, Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> 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 >> > > Because not all platforms support it and it's the simplest way of Platforms like SoCs or boards? > marking the ones that do. Both SHM and SCM nodes sit on the firmware > node anyway. What do you recommend? A property of the SCM node? Like > 'qcom,shm-bridge` or something? If the first - you talk about SoCs - then you have everything needed already: SCM compatibles. This defines it fully. If it varies by boards with one SoC, would be different case, but I really doubt it. Best regards, Krzysztof
