On Wed, 30 Aug 2023 at 16:58, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > 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. > Ok, makes sense. Thanks. Bartosz
