From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24C4DC433E2 for ; Wed, 2 Sep 2020 22:14:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ECECC20767 for ; Wed, 2 Sep 2020 22:14:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599084861; bh=ZCFroikHqWpI8jWQzY+9ojVRjacJ91thS4gwrKCgZII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=hdkp8COjBW0r2MBPOmoLCo66xkzavJE5DwdxMV1zmauxonee9Y0JBE7O0cxpGwcew M/3AHpacEwEDMIJ8Pem2/1wZ5RvFRm5AK5xBu7SMIZQiPCHZf5g+XZOn6VnNAk0kHE yVgc+Zhnt6eVTG4kk6b3zfXFKXzY5LU7Eg7tmzV4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726678AbgIBWOT (ORCPT ); Wed, 2 Sep 2020 18:14:19 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:34761 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726226AbgIBWOT (ORCPT ); Wed, 2 Sep 2020 18:14:19 -0400 Received: by mail-io1-f65.google.com with SMTP id m17so630373ioo.1 for ; Wed, 02 Sep 2020 15:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=QPY9nMiYO0gvLwu+EkpnSfHt0Ye+AiRUCpiv0PRhkww=; b=GstG4bbqZp2kZ89o2OoHC82pVSaEXvjfQsS8g0KxXHjtglcQR3icfvAR7il8a6ElEd nBksE7JwvdLg215bIGUvRSyUr3W77WFj7zSoBDEY3/AVfWcfqaDojm6RMWdYhObqiM/T rJHPQwHygBlMMRyAxmEfGR35EHFx/5qJGu8xhRDK2RIYoJq5DB7pOoKoqVAiyCs6a5MC mRqcU/EO4L9w87YglgQrvH9gJlJmj9pTtmJi9nkvq65dpEHDMubWk8htfalZCoK8LxGC EWf04QAuv2zAzRoO/VCxX4gW0F/Iy5MXpqeIW8e4Qzhpy6I0507EZXDu8w7pfO+5Kf79 syQA== X-Gm-Message-State: AOAM532ozehhmotrKNuLKiiBDbUaYAl16l8p5hXY1bNOFzEDfbFKwGZj xJvScozBfJe9gPc5hwUsjQ== X-Google-Smtp-Source: ABdhPJy4pjbq8+MszwqqvbM4UvuG4em416/8kblY4uK8C8Q247cam8xaSPUwLgeDDwGYS+zkAYUCEQ== X-Received: by 2002:a02:1649:: with SMTP id a70mr156346jaa.39.1599084856950; Wed, 02 Sep 2020 15:14:16 -0700 (PDT) Received: from xps15 ([64.188.179.249]) by smtp.gmail.com with ESMTPSA id z26sm447201ilf.60.2020.09.02.15.14.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2020 15:14:16 -0700 (PDT) Received: (nullmailer pid 1463168 invoked by uid 1000); Wed, 02 Sep 2020 22:14:13 -0000 Date: Wed, 2 Sep 2020 16:14:13 -0600 From: Rob Herring To: Sudeep Holla Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, kernel-team@android.com, Will Deacon , tsoni@quicinc.com, pratikp@quicinc.com Subject: Re: [PATCH 1/9] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Message-ID: <20200902221413.GB1410716@bogus> References: <20200829170923.29949-1-sudeep.holla@arm.com> <20200829170923.29949-2-sudeep.holla@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200829170923.29949-2-sudeep.holla@arm.com> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sat, Aug 29, 2020 at 06:09:15PM +0100, Sudeep Holla wrote: > From: Will Deacon > > Add devicetree bindings for a FF-A-compliant hypervisor, its partitions > and their memory regions. The naming is ludicrous but also not by fault. > > Signed-off-by: Will Deacon > (sudeep.holla: Dropped PSA from name and elsewhere as it seem to have > disappeared mysteriously just before the final release) > Signed-off-by: Sudeep Holla > --- > .../devicetree/bindings/arm/arm,ffa.yaml | 102 ++++++++++++++++++ > .../reserved-memory/arm,ffa-memory.yaml | 71 ++++++++++++ > 2 files changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml > create mode 100644 Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > > diff --git a/Documentation/devicetree/bindings/arm/arm,ffa.yaml b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > new file mode 100644 > index 000000000000..668a5995fcab > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > @@ -0,0 +1,102 @@ > +# SPDX-License-Identifier: GPL-2.0 Dual license new bindings: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/arm,ffa.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + Firmware frameworks implementing partition setup according to the FF-A > + specification defined by ARM document number ARM DEN 0077A ("Arm Firmware > + Framework for Arm v8-A") [0] must provide a "manifest and image" for each > + partition to the "partition manager" so that the partition execution contexts > + can be initialised. > + > + In the case of a virtual FFA instance, the manifest and image details can be > + passed to the hypervisor (e.g. Linux KVM) using this binding. > + > + [0] https://developer.arm.com/docs/den0077/latest There's efforts to define 'system DT' describing all the CPUs in a system (such as both A and R cores) as well as physical partitioning. I'm not sure that virtual partitioning would need a different binding. Or at least there's probably some overlap. > + > +properties: > + $nodename: > + const: ffa_hyp > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-hypervisor > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: | > + A phandle to the reserved memory region [1] to be used by the hypervisor. > + The reserved memory region must be compatible with > + "arm,ffa-1.0-hypervisor-memory-region". > + > + [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +patternProperties: > + "^ffa_partition[0-9]+$": s/_/-/ Probably should use 'reg' to number partitions. Is the numbering significant? > + type: object > + description: One or more child nodes, each describing an FFA partition. > + properties: > + $nodename: > + const: ffa_partition > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-partition > + > + uuid: > + $ref: '/schemas/types.yaml#definitions/string' json-schema can do better here: format: uuid Though 'format' will need to be allowed in our meta-schema. > + description: | > + The 128-bit UUID [2] of the service implemented by this partition. > + > + [2] https://tools.ietf.org/html/rfc4122 > + > + nr-exec-ctxs: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: | > + The number of virtual CPUs to instantiate for this partition. Just 'nr-cpus' would be clearer in my opinion. What happens on big.LITTLE? > + > + exec-state: > + description: The execution state in which to execute the partition. > + oneOf: > + - const: "AArch64" > + - const: "AArch32" Why is this needed? We don't need anything like this for KVM today. > + > + entry-point: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The entry address of the partition specified as an Intermediate > + Physical Address (IPA) encoded according to the '#address-cells' > + property. Is the address unique or you could have the same image for multiple partitions? If unique, then you could use 'reg' here. You didn't document using '#address-cells'. Really, I'd just make this a fixed uint64 (if not 'reg'). > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle-array' > + description: | > + A list of phandles to FFA reserved memory regions [3] for this > + partition. > + > + [3] Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > + > +additionalProperties: false > + > +examples: > + - | > + ffa_hyp { > + compatible = "arm,ffa-1.0-hypervisor"; > + memory-region = <&ffa_hyp_reserved>; > + > + ffa_partition0 { > + compatible = "arm,ffa-1.0-partition"; > + uuid = "12345678-9abc-def0-1234-56789abcdef0"; > + nr-exec-ctxs = <2>; > + exec-state = "AArch64"; > + entry-point = <0x80000>; > + memory-region = <&ffa_reserved0 &ffa_reserved1>; > + }; > + }; > diff --git a/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > new file mode 100644 > index 000000000000..5335e07abcfc > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > @@ -0,0 +1,71 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/arm,ffa-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memory Region for Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + This binding allows a FF-A implementation to describe the normal memory > + regions of a partition [1] to a hypervisor according to [2]. > + > + The physical address range reserved for the partition can be specified as a > + static allocation using the 'reg' property or as a dynamic allocation using > + the 'size' property. If both properties are omitted, then the hypervisor can > + allocate physical memory for the partition however it sees fit. > + > + [1] Documentation/devicetree/bindings/arm/arm,ffa.yaml > + [2] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +properties: > + $nodename: > + pattern: "^ffa_mem(@[0-9a-f]+)?$" > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-partition-memory-region > + > + ipa-range: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The Intermediate Physical Address (IPA) range (encoded in the same way as > + a 'reg' property) at which to map the physical memory. If the IPA range is > + larger than the physical memory region then the region is mapped starting > + at the base of the IPA range. > + > + read-only: > + type: boolean > + description: | > + (static allocation only) The memory region has been pre-populated > + by the firmware framework and must be mapped without write permission > + at stage 2. > + > + non-executable: > + type: boolean > + description: | > + The memory region must be mapped without execute permission at stage 2. > + > + > +required: > + - compatible > + > +# The "reserved-memory" binding defines additional properties. > +additionalProperties: true > + > +examples: > + - | > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + > + ffa_reserved0: ffa_mem@100000000 { > + compatible = "arm,ffa-1.0-partition-memory-region"; > + reg = <0x1 0x0 0x0 0x04000000>; // 64M @ 1GB > + ipa-range = <0x0 0x0 0x0 0x04000000>; // 64M @ 0x0 So we need the PA and IPA? We're using DT to define stage 2 page tables... > + read-only; > + }; > + }; > -- > 2.17.1 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A7BBC433E7 for ; Wed, 2 Sep 2020 22:16:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DC91F2078E for ; Wed, 2 Sep 2020 22:16:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="W9OtbGhS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC91F2078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SLuf910enxOU0VT9k4vCsvtG9mqXzd2tJniAaEzVoRQ=; b=W9OtbGhSz4A7vo9sEDeXQRJZ7 vMCjW7HfL0Wxi9HaMMndJL23a7RoVNCPnEFAOYZ9qMijj6J6FG7pu/5vdxMLZkP/lzucxmhTzSA/u 4jyAjoihO5uF8wmcOq1y+sS1fQ5F2j6EF2fGVrMnukLcmnZnyE5IPfOaR0wS4JSH/lB8pJ6X+arvb iEWpJztcAraDbAh2vk7t8pu41YfLbtOxl+PRaZkSF4yy5gvoqgsdhzR1ACfPtQQSm1EhE8/O3f2aI pPGVo1cNEYL0yas0I3uFCvhCpoPrfvyJCa/UOv6mqP3rfUuTxm4OzW/uee/aIC05zuvj3YD1rEXUm /WKi0BJuw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDb1L-0005eF-Vx; Wed, 02 Sep 2020 22:14:24 +0000 Received: from mail-io1-f66.google.com ([209.85.166.66]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDb1H-0005cf-Uo for linux-arm-kernel@lists.infradead.org; Wed, 02 Sep 2020 22:14:21 +0000 Received: by mail-io1-f66.google.com with SMTP id m23so581714iol.8 for ; Wed, 02 Sep 2020 15:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=QPY9nMiYO0gvLwu+EkpnSfHt0Ye+AiRUCpiv0PRhkww=; b=n8HP7DDPvAW86CA6Mqib9SlZaoIT1QNfkpFt755Avpzn568a0FqCDEATRJn8QyGuzc fMxBJF7zT2Z1FqhrZZB6Z/ZCIY8LyjxnC0t32+MrFI9js2ZAZzV7h0JoYL3x95eyHtaO bgh2D/w1VGKu6Jiram+9eg70UKpyYd3nbl6XdB2pa2VDJhzo4LjmDry8RIUsSv2+2mAi CpcUC18njMGrxeuGuR9a771zjgGzUX8c/ZwVYtDhN7mpFpKmKvUjaJAP9wmNTCBkJMwq Ei3LunJZHEeMOu5PmmGNlHPF5GdnDoxDQB71lj9DfwuM3Lo5PuRj3gqccEBiu6UGv715 JHaA== X-Gm-Message-State: AOAM530gAvgVqQMN8S4EeBj0KKDvmxUaU2shPYS6kZJt5G5/YEGyP/eo HDYL0oH1j/Xg5ARVRKXBxXI9VFqTIE7X X-Google-Smtp-Source: ABdhPJy4pjbq8+MszwqqvbM4UvuG4em416/8kblY4uK8C8Q247cam8xaSPUwLgeDDwGYS+zkAYUCEQ== X-Received: by 2002:a02:1649:: with SMTP id a70mr156346jaa.39.1599084856950; Wed, 02 Sep 2020 15:14:16 -0700 (PDT) Received: from xps15 ([64.188.179.249]) by smtp.gmail.com with ESMTPSA id z26sm447201ilf.60.2020.09.02.15.14.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2020 15:14:16 -0700 (PDT) Received: (nullmailer pid 1463168 invoked by uid 1000); Wed, 02 Sep 2020 22:14:13 -0000 Date: Wed, 2 Sep 2020 16:14:13 -0600 From: Rob Herring To: Sudeep Holla Subject: Re: [PATCH 1/9] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Message-ID: <20200902221413.GB1410716@bogus> References: <20200829170923.29949-1-sudeep.holla@arm.com> <20200829170923.29949-2-sudeep.holla@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200829170923.29949-2-sudeep.holla@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200902_181420_034682_A7E168BA X-CRM114-Status: GOOD ( 33.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, kernel-team@android.com, pratikp@quicinc.com, tsoni@quicinc.com, Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Aug 29, 2020 at 06:09:15PM +0100, Sudeep Holla wrote: > From: Will Deacon > > Add devicetree bindings for a FF-A-compliant hypervisor, its partitions > and their memory regions. The naming is ludicrous but also not by fault. > > Signed-off-by: Will Deacon > (sudeep.holla: Dropped PSA from name and elsewhere as it seem to have > disappeared mysteriously just before the final release) > Signed-off-by: Sudeep Holla > --- > .../devicetree/bindings/arm/arm,ffa.yaml | 102 ++++++++++++++++++ > .../reserved-memory/arm,ffa-memory.yaml | 71 ++++++++++++ > 2 files changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml > create mode 100644 Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > > diff --git a/Documentation/devicetree/bindings/arm/arm,ffa.yaml b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > new file mode 100644 > index 000000000000..668a5995fcab > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > @@ -0,0 +1,102 @@ > +# SPDX-License-Identifier: GPL-2.0 Dual license new bindings: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/arm,ffa.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + Firmware frameworks implementing partition setup according to the FF-A > + specification defined by ARM document number ARM DEN 0077A ("Arm Firmware > + Framework for Arm v8-A") [0] must provide a "manifest and image" for each > + partition to the "partition manager" so that the partition execution contexts > + can be initialised. > + > + In the case of a virtual FFA instance, the manifest and image details can be > + passed to the hypervisor (e.g. Linux KVM) using this binding. > + > + [0] https://developer.arm.com/docs/den0077/latest There's efforts to define 'system DT' describing all the CPUs in a system (such as both A and R cores) as well as physical partitioning. I'm not sure that virtual partitioning would need a different binding. Or at least there's probably some overlap. > + > +properties: > + $nodename: > + const: ffa_hyp > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-hypervisor > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: | > + A phandle to the reserved memory region [1] to be used by the hypervisor. > + The reserved memory region must be compatible with > + "arm,ffa-1.0-hypervisor-memory-region". > + > + [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +patternProperties: > + "^ffa_partition[0-9]+$": s/_/-/ Probably should use 'reg' to number partitions. Is the numbering significant? > + type: object > + description: One or more child nodes, each describing an FFA partition. > + properties: > + $nodename: > + const: ffa_partition > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-partition > + > + uuid: > + $ref: '/schemas/types.yaml#definitions/string' json-schema can do better here: format: uuid Though 'format' will need to be allowed in our meta-schema. > + description: | > + The 128-bit UUID [2] of the service implemented by this partition. > + > + [2] https://tools.ietf.org/html/rfc4122 > + > + nr-exec-ctxs: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: | > + The number of virtual CPUs to instantiate for this partition. Just 'nr-cpus' would be clearer in my opinion. What happens on big.LITTLE? > + > + exec-state: > + description: The execution state in which to execute the partition. > + oneOf: > + - const: "AArch64" > + - const: "AArch32" Why is this needed? We don't need anything like this for KVM today. > + > + entry-point: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The entry address of the partition specified as an Intermediate > + Physical Address (IPA) encoded according to the '#address-cells' > + property. Is the address unique or you could have the same image for multiple partitions? If unique, then you could use 'reg' here. You didn't document using '#address-cells'. Really, I'd just make this a fixed uint64 (if not 'reg'). > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle-array' > + description: | > + A list of phandles to FFA reserved memory regions [3] for this > + partition. > + > + [3] Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > + > +additionalProperties: false > + > +examples: > + - | > + ffa_hyp { > + compatible = "arm,ffa-1.0-hypervisor"; > + memory-region = <&ffa_hyp_reserved>; > + > + ffa_partition0 { > + compatible = "arm,ffa-1.0-partition"; > + uuid = "12345678-9abc-def0-1234-56789abcdef0"; > + nr-exec-ctxs = <2>; > + exec-state = "AArch64"; > + entry-point = <0x80000>; > + memory-region = <&ffa_reserved0 &ffa_reserved1>; > + }; > + }; > diff --git a/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > new file mode 100644 > index 000000000000..5335e07abcfc > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > @@ -0,0 +1,71 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/arm,ffa-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memory Region for Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + This binding allows a FF-A implementation to describe the normal memory > + regions of a partition [1] to a hypervisor according to [2]. > + > + The physical address range reserved for the partition can be specified as a > + static allocation using the 'reg' property or as a dynamic allocation using > + the 'size' property. If both properties are omitted, then the hypervisor can > + allocate physical memory for the partition however it sees fit. > + > + [1] Documentation/devicetree/bindings/arm/arm,ffa.yaml > + [2] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +properties: > + $nodename: > + pattern: "^ffa_mem(@[0-9a-f]+)?$" > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-partition-memory-region > + > + ipa-range: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The Intermediate Physical Address (IPA) range (encoded in the same way as > + a 'reg' property) at which to map the physical memory. If the IPA range is > + larger than the physical memory region then the region is mapped starting > + at the base of the IPA range. > + > + read-only: > + type: boolean > + description: | > + (static allocation only) The memory region has been pre-populated > + by the firmware framework and must be mapped without write permission > + at stage 2. > + > + non-executable: > + type: boolean > + description: | > + The memory region must be mapped without execute permission at stage 2. > + > + > +required: > + - compatible > + > +# The "reserved-memory" binding defines additional properties. > +additionalProperties: true > + > +examples: > + - | > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + > + ffa_reserved0: ffa_mem@100000000 { > + compatible = "arm,ffa-1.0-partition-memory-region"; > + reg = <0x1 0x0 0x0 0x04000000>; // 64M @ 1GB > + ipa-range = <0x0 0x0 0x0 0x04000000>; // 64M @ 0x0 So we need the PA and IPA? We're using DT to define stage 2 page tables... > + read-only; > + }; > + }; > -- > 2.17.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel