Message ID | 20231111111559.8218-7-yong.wu@mediatek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp171733vqg; Sat, 11 Nov 2023 03:18:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IHxTzUaeDi5RNNsWfEbIjuDd80VhKUEkKPeUrbD/4dYzgOF4+3T3P1N8zTAm7McJ/HvGHYg X-Received: by 2002:a05:6870:51ca:b0:1f4:d2df:c53c with SMTP id b10-20020a05687051ca00b001f4d2dfc53cmr1737261oaj.24.1699701490034; Sat, 11 Nov 2023 03:18:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699701490; cv=none; d=google.com; s=arc-20160816; b=r1RfVoSa0UgNddX7LXdzgugrOf6+G24lt5rYG7vo+RvS74JyCSU0h9lU3LW61208NC Eh9IdJPme0xQE37mZ2AJArchPKO/FVdmzfaYa777qQDpvR9dhli+Tng2wKlZqVXHUi8g w2y9GB0zD5T/0wgrNW4aDIXSGiKQ0Z6FFS8qfUHpXDdRttOqSvDIlJK8ErT3TGs9ntoV YlXc2hKpmBzkN+A6wMYxODhwPAXKni09Xgok6YQjBlQ/YLOKb1xxtKWes7MCLiWOcPqM 1eFFk58A/VI4c9Q87VAjhV4qM123nsWqOJ6xWw93Z4rv5A4Ln8V6IAfCX1ghKX7y7Vpw MCUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=h0jwM9zWwa5D3l5JQgrd0AZPHaBGPLCLDPqIefNNn9w=; fh=OWZGSeDk0Aqy44JQD4a9BiWeZfTHmrW0DBRG2LLmKkg=; b=1DkYnjwsnG1IzPvEQhhMKGbCD1OZ5AfQTUyDJ01uZKpnCgN9itQz5ss32GaCfacOE1 ZaDhv0VhZQpu9GNO5gOeUTBOBNCFa65rJ1Ev8iyM7QAvZq0BLo8KTgm+GVrOWh8J9EbK 0jN9Eo/lSrQKQHweYgPwtc8niXG4fwYfJXHGIPHCjra6oYmdlsfg9I60V7waiBspkOvu 9v/d2ukFZtQ8egvuIMHZzZEP/qRkhPpUU5UQSyd4xVNWYo5+MCAvV8PSKVPcmyRqYaYB dir2J9uo4+3CvkeT2QSgj1+vieq9yyGij+BUC17f0vcAHMqE09VE5JC070QHf5v1V4Uk N7HQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=M3Pyx07E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id q12-20020a056a00150c00b006b1fc88d095si1576502pfu.71.2023.11.11.03.18.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Nov 2023 03:18:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=M3Pyx07E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 4E0B781A9EFF; Sat, 11 Nov 2023 03:18:06 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230496AbjKKLRv (ORCPT <rfc822;heyuhang3455@gmail.com> + 29 others); Sat, 11 Nov 2023 06:17:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230145AbjKKLRu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 11 Nov 2023 06:17:50 -0500 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D385469A; Sat, 11 Nov 2023 03:17:45 -0800 (PST) X-UUID: ed1ba80a808311eea33bb35ae8d461a2-20231111 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=h0jwM9zWwa5D3l5JQgrd0AZPHaBGPLCLDPqIefNNn9w=; b=M3Pyx07EbPyVhoaPt7nZ/FX16J/WlhF9ReDp2DytfLanRl1hkcg6DJdyygoeHF2cbwXDCfRX82H8qu2ioElOiHgeLvmHJGj2MW1aJeNBT/qKTxMah3Qdlug+Tmq7Xql32hK/AcLwgauDx1jtXqluSjT8HK/5nO3HQAQUqaFm+do=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.33,REQID:eeace6ff-da5e-403e-a8d4-6413bef47f5d,IP:0,U RL:25,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:25 X-CID-META: VersionHash:364b77b,CLOUDID:7ff2f05f-c89d-4129-91cb-8ebfae4653fc,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:1,EDM:-3,IP:nil,U RL:11|1,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1,SPR: NO,DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 0 X-CID-BAS: 0,_,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR,TF_CID_SPAM_ULN X-UUID: ed1ba80a808311eea33bb35ae8d461a2-20231111 Received: from mtkmbs13n2.mediatek.inc [(172.21.101.108)] by mailgw01.mediatek.com (envelope-from <yong.wu@mediatek.com>) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 769761032; Sat, 11 Nov 2023 19:17:40 +0800 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by MTKMBS14N1.mediatek.inc (172.21.101.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Sat, 11 Nov 2023 19:17:37 +0800 Received: from mhfsdcap04.gcn.mediatek.inc (10.17.3.154) by mtkmbs11n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Sat, 11 Nov 2023 19:17:36 +0800 From: Yong Wu <yong.wu@mediatek.com> To: Rob Herring <robh+dt@kernel.org>, Sumit Semwal <sumit.semwal@linaro.org>, <christian.koenig@amd.com>, Matthias Brugger <matthias.bgg@gmail.com> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Benjamin Gaignard <benjamin.gaignard@collabora.com>, Brian Starkey <Brian.Starkey@arm.com>, John Stultz <jstultz@google.com>, <tjmercier@google.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Yong Wu <yong.wu@mediatek.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>, <dri-devel@lists.freedesktop.org>, <linaro-mm-sig@lists.linaro.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <jianjiao.zeng@mediatek.com>, <kuohong.wang@mediatek.com>, Vijayanand Jitta <quic_vjitta@quicinc.com>, Joakim Bech <joakim.bech@linaro.org>, Jeffrey Kardatzke <jkardatzke@google.com>, Nicolas Dufresne <nicolas@ndufresne.ca>, <ckoenig.leichtzumerken@gmail.com> Subject: [PATCH v2 6/8] dt-bindings: reserved-memory: Add secure CMA reserved memory range Date: Sat, 11 Nov 2023 19:15:57 +0800 Message-ID: <20231111111559.8218-7-yong.wu@mediatek.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20231111111559.8218-1-yong.wu@mediatek.com> References: <20231111111559.8218-1-yong.wu@mediatek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-TM-AS-Product-Ver: SMEX-14.0.0.3152-9.1.1006-23728.005 X-TM-AS-Result: No-10--3.888000-8.000000 X-TMASE-MatchedRID: y64C6oV0e4cXSulpnju2H8LPXKYZysJRecvjbu/xDjpMOjKUxCZwrxVq ALLbOC6VBRj5e39v/eGsMR/ATxTHjSWvhQBtQUwTyeVujmXuYYX+yhO1yCoLfDP3WYNhkszluHQ 5SWRKq/0I49goOhQ2+ItfNuTBizUEQF24kZp9Ww+eAiCmPx4NwGmRqNBHmBvejvEeq6gAkYbfaY 87m2dqx9934/rDAK3zCaXr04pRMJA1yGL4+nAmxJD/HwNezREOO8fzLmP53G+oHvd3pfFwUF+/A KUOIHlXyFVWUnr9FwsfFdcY8tD7GQ6w2+Ixe72XP1JC+7l10KltUY6LqdlQnFr3vnlc+D6eVZOb rZkNVZRlRd/nfa56MV7IEEqsePYG X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--3.888000-8.000000 X-TMASE-Version: SMEX-14.0.0.3152-9.1.1006-23728.005 X-TM-SNTS-SMTP: C04951FF99BF27E30025E22F729504596E746D2DEA39644EF37717C76995E8582000:8 X-MTK: N X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Sat, 11 Nov 2023 03:18:06 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782266189228325265 X-GMAIL-MSGID: 1782266189228325265 |
Series |
dma-buf: heaps: Add secure heap
|
|
Commit Message
Yong Wu
Nov. 11, 2023, 11:15 a.m. UTC
Add a binding for describing the secure CMA reserved memory range. The
memory range also will be defined in the TEE firmware. It means the TEE
will be configured with the same address/size that is being set in this
DT node.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
.../reserved-memory/secure_cma_region.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml
Comments
On 11/11/2023 12:15, Yong Wu wrote: > Add a binding for describing the secure CMA reserved memory range. The > memory range also will be defined in the TEE firmware. It means the TEE > will be configured with the same address/size that is being set in this > DT node. > > Signed-off-by: Yong Wu <yong.wu@mediatek.com> > --- What was the outcome of previous discussion? I don't see any references to the conclusion and your changelog "Reword the dt-binding description" is way too generic. You must explain what happened here. > .../reserved-memory/secure_cma_region.yaml | 44 +++++++++++++++++++ > 1 file changed, 44 insertions(+) > create mode 100644 Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml > > diff --git a/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml b/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml > new file mode 100644 > index 000000000000..8ab559595fbe > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml > @@ -0,0 +1,44 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/secure_cma_region.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Secure Reserved CMA Region > + > +description: > + This binding describes a CMA region that can dynamically transition Describe the hardware or firmware, not the binding. Drop first four words and rephrase it. > +between secure and non-secure states that a TEE can allocate memory > +from. It does not look like you tested the bindings, at least after quick look. Please run `make dt_binding_check` (see Documentation/devicetree/bindings/writing-schema.rst for instructions). Maybe you need to update your dtschema and yamllint. Do not send untested code. > + > +maintainers: > + - Yong Wu <yong.wu@mediatek.com> > + > +allOf: > + - $ref: reserved-memory.yaml > + > +properties: > + compatible: > + const: secure_cma_region Still wrong compatible. Look at other bindings - there is nowhere underscore. Look at other reserved memory bindings especially. Also, CMA is a Linux thingy, so either not suitable for bindings at all, or you need Linux specific compatible. I don't quite get why do you even put CMA there - adding Linux specific stuff will get obvious pushback... > + > +required: > + - compatible > + - reg > + - reusable > + > +unevaluatedProperties: false > + > +examples: > + - | > + Stray blank line. > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + reserved-memory@80000000 { > + compatible = "secure_cma_region"; > + reusable; > + reg = <0x80000000 0x18000000>; reg is second property. Open DTS and check how it is there. > + }; > + }; Best regards, Krzysztof
On Sat, 2023-11-11 at 13:48 +0100, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 11/11/2023 12:15, Yong Wu wrote: > > Add a binding for describing the secure CMA reserved memory range. > The > > memory range also will be defined in the TEE firmware. It means the > TEE > > will be configured with the same address/size that is being set in > this > > DT node. > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com> > > --- > > What was the outcome of previous discussion? I don't see any > references > to the conclusion and your changelog "Reword the dt-binding > description" > is way too generic. > > You must explain what happened here. I don't think there is a final conclusion yet in v1. Jeff helped explain that this region also is defined in TEE firmware. I put this a bit in the commit message above. Sorry for confusing. > > > .../reserved-memory/secure_cma_region.yaml | 44 > +++++++++++++++++++ > > 1 file changed, 44 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/reserved- > memory/secure_cma_region.yaml > > > > diff --git a/Documentation/devicetree/bindings/reserved- > memory/secure_cma_region.yaml > b/Documentation/devicetree/bindings/reserved- > memory/secure_cma_region.yaml > > new file mode 100644 > > index 000000000000..8ab559595fbe > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/reserved- > memory/secure_cma_region.yaml > > @@ -0,0 +1,44 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > http://devicetree.org/schemas/reserved-memory/secure_cma_region.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Secure Reserved CMA Region Will change to: Secure Region. Is it ok? > > + > > +description: > > + This binding describes a CMA region that can dynamically > transition > > Describe the hardware or firmware, not the binding. Drop first four > words and rephrase it. Memory region for TEE usage, which is also defined in the TEE firmware. When an activity (e.g. secure video playback) requiring usage of this starts, this region will be protected by MPU (Memory Protect Unit) in the TEE firmware. After the activity is completed, the region will be unprotected by the TEE and usable by the non-secure side (i.e. kernel and userspace). Does this description make sense for you? > > > +between secure and non-secure states that a TEE can allocate > memory > > +from. > > It does not look like you tested the bindings, at least after quick > look. Please run `make dt_binding_check` (see > Documentation/devicetree/bindings/writing-schema.rst for > instructions). > Maybe you need to update your dtschema and yamllint. > > Do not send untested code. Sorry. I will update them and test this before sending. > > > + > > +maintainers: > > + - Yong Wu <yong.wu@mediatek.com> > > + > > +allOf: > > + - $ref: reserved-memory.yaml > > + > > +properties: > > + compatible: > > + const: secure_cma_region > > Still wrong compatible. Look at other bindings - there is nowhere > underscore. Look at other reserved memory bindings especially. > > Also, CMA is a Linux thingy, so either not suitable for bindings at > all, > or you need Linux specific compatible. I don't quite get why do you > evennot > put CMA there - adding Linux specific stuff will get obvious > pushback... Thanks. I will change to: secure-region. Is this ok? > > > > + > > +required: > > + - compatible > > + - reg > > + - reusable > > + > > +unevaluatedProperties: false > > + > > +examples: > > + - | > > + > > Stray blank line. Thanks for reviewing so careful. Will fix this and below. > > > + reserved-memory { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges; > > + > > + reserved-memory@80000000 { > > + compatible = "secure_cma_region"; > > + reusable; > > + reg = <0x80000000 0x18000000>; > > reg is second property. Open DTS and check how it is there. > > > + }; > > + }; > > Best regards, > Krzysztof >
On Sat, 11 Nov 2023 19:15:57 +0800, Yong Wu wrote: > Add a binding for describing the secure CMA reserved memory range. The > memory range also will be defined in the TEE firmware. It means the TEE > will be configured with the same address/size that is being set in this > DT node. > > Signed-off-by: Yong Wu <yong.wu@mediatek.com> > --- > .../reserved-memory/secure_cma_region.yaml | 44 +++++++++++++++++++ > 1 file changed, 44 insertions(+) > create mode 100644 Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml:12:1: [error] syntax error: could not find expected ':' (syntax) dtschema/dtc warnings/errors: make[2]: *** Deleting file 'Documentation/devicetree/bindings/reserved-memory/secure_cma_region.example.dts' Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml:12:1: could not find expected ':' make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/reserved-memory/secure_cma_region.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs.... ./Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml:12:1: could not find expected ':' /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml: ignoring, error parsing file make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1427: dt_binding_check] Error 2 make: *** [Makefile:234: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231111111559.8218-7-yong.wu@mediatek.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On 13/11/2023 6:37 am, Yong Wu (吴勇) wrote: [...] >>> +properties: >>> + compatible: >>> + const: secure_cma_region >> >> Still wrong compatible. Look at other bindings - there is nowhere >> underscore. Look at other reserved memory bindings especially. >> >> Also, CMA is a Linux thingy, so either not suitable for bindings at >> all, >> or you need Linux specific compatible. I don't quite get why do you >> evennot >> put CMA there - adding Linux specific stuff will get obvious >> pushback... > > Thanks. I will change to: secure-region. Is this ok? No, the previous discussion went off in entirely the wrong direction. To reiterate, the point of the binding is not to describe the expected usage of the thing nor the general concept of the thing, but to describe the actual thing itself. There are any number of different ways software may interact with a "secure region", so that is meaningless as a compatible. It needs to describe *this* secure memory interface offered by *this* TEE, so that software knows that to use it requires making those particular SiP calls with that particular UUID etc. Thanks, Robin.
May I suggest the following for the device tree binding? (I'm not very familiar w/ device trees, so apologies for any oversights, but trying to process the feedback here and help move Mediatek along). This should align with my other suggestions for having an MTK specific portion to their secure heap implementation; which also means there should be an MTK specific device tree binding. # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/reserved-memory/mediatek,dynamic-secure-region.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Mediatek Dynamic Reserved Region description: A memory region that can dynamically transition as a whole between secure and non-secure states. This memory will be protected by OP-TEE when allocations are active and unprotected otherwise. maintainers: - Yong Wu <yong.wu@mediatek.com> allOf: - $ref: reserved-memory.yaml properties: compatible: const: mediatek,dynamic-secure-region required: - compatible - reg - reusable unevaluatedProperties: false examples: - | reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; reserved-memory@80000000 { compatible = "mediatek,dynamic-secure-region"; reusable; reg = <0x80000000 0x18000000>; }; }; On Tue, Nov 14, 2023 at 5:18 AM Robin Murphy <robin.murphy@arm.com> wrote: > > On 13/11/2023 6:37 am, Yong Wu (吴勇) wrote: > [...] > >>> +properties: > >>> + compatible: > >>> + const: secure_cma_region > >> > >> Still wrong compatible. Look at other bindings - there is nowhere > >> underscore. Look at other reserved memory bindings especially. > >> > >> Also, CMA is a Linux thingy, so either not suitable for bindings at > >> all, > >> or you need Linux specific compatible. I don't quite get why do you > >> evennot > >> put CMA there - adding Linux specific stuff will get obvious > >> pushback... > > > > Thanks. I will change to: secure-region. Is this ok? > > No, the previous discussion went off in entirely the wrong direction. To > reiterate, the point of the binding is not to describe the expected > usage of the thing nor the general concept of the thing, but to describe > the actual thing itself. There are any number of different ways software > may interact with a "secure region", so that is meaningless as a > compatible. It needs to describe *this* secure memory interface offered > by *this* TEE, so that software knows that to use it requires making > those particular SiP calls with that particular UUID etc. > > Thanks, > Robin.
diff --git a/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml b/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml new file mode 100644 index 000000000000..8ab559595fbe --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/secure_cma_region.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Secure Reserved CMA Region + +description: + This binding describes a CMA region that can dynamically transition +between secure and non-secure states that a TEE can allocate memory +from. + +maintainers: + - Yong Wu <yong.wu@mediatek.com> + +allOf: + - $ref: reserved-memory.yaml + +properties: + compatible: + const: secure_cma_region + +required: + - compatible + - reg + - reusable + +unevaluatedProperties: false + +examples: + - | + + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + reserved-memory@80000000 { + compatible = "secure_cma_region"; + reusable; + reg = <0x80000000 0x18000000>; + }; + };