| Message ID | 20200829170923.29949-2-sudeep.holla@arm.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | firmware: Add initial support for Arm FF-A | expand |
On Sat, 29 Aug 2020 18:09:15 +0100 Sudeep Holla <sudeep.holla@arm.com> wrote: > From: Will Deacon <will@kernel.org> > > 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 <will@kernel.org> > (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 <sudeep.holla@arm.com> As I was reading this out of curiosity... I'm far from a yaml expert but a few things in line. > --- > .../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 > +%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 <will@kernel.org> > + > +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 > + > +properties: > + $nodename: > + const: ffa_hyp > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-hypervisor As below, would enum be more appropriate here? > + > + 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]+$": > + type: object > + description: One or more child nodes, each describing an FFA partition. > + properties: > + $nodename: > + const: ffa_partition > + > + compatible: > + oneOf: enum? > + - const: arm,ffa-1.0-partition > + > + uuid: > + $ref: '/schemas/types.yaml#definitions/string' > + description: | > + The 128-bit UUID [2] of the service implemented by this partition. > + > + [2] https://tools.ietf.org/html/rfc4122 Feels like we should be able to better type wise than a string for this but maybe not... Doesn't seem to be much in the way of precedence. > + > + nr-exec-ctxs: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: | > + The number of virtual CPUs to instantiate for this partition. > + > + exec-state: > + description: The execution state in which to execute the partition. > + oneOf: > + - const: "AArch64" > + - const: "AArch32" > + > + 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. > + > + 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 <will@kernel.org> > + > +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 If there is just element and it is const why not just? compatible: const: .... I guess it sort of future proofs you for later variants... However in that case, it would be more common to use compatible: enum: - arm,ffa... which is more restrictive but doesn't seem like you need the complexity of oneOf and it's handling of sub schemas here. > + > + 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 Isn't that at 4GB? > + ipa-range = <0x0 0x0 0x0 0x04000000>; // 64M @ 0x0 > + read-only; > + }; > + };
On Sat, Aug 29, 2020 at 06:09:15PM +0100, Sudeep Holla wrote: > From: Will Deacon <will@kernel.org> > > 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 <will@kernel.org> > (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 <sudeep.holla@arm.com> > --- > .../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 <will@kernel.org> > + > +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 <will@kernel.org> > + > +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 >
On Tue, Sep 01, 2020 at 05:03:54PM +0100, Jonathan Cameron wrote: > On Sat, 29 Aug 2020 18:09:15 +0100 > Sudeep Holla <sudeep.holla@arm.com> wrote: > > > From: Will Deacon <will@kernel.org> > > > > 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 <will@kernel.org> > > (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 <sudeep.holla@arm.com> > > As I was reading this out of curiosity... > Thanks for the review, all comments taken and incorporated in all other patches. I will look at this yaml in detail soon. -- Regards, Sudeep
On Wed, Sep 02, 2020 at 04:14:13PM -0600, Rob Herring wrote: > On Sat, Aug 29, 2020 at 06:09:15PM +0100, Sudeep Holla wrote: > > From: Will Deacon <will@kernel.org> > > > > 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 <will@kernel.org> > > (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 <sudeep.holla@arm.com> > > --- > > .../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 <will@kernel.org> > > + > > +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? > Not really, the partitions will get IDs assigned by Hypervisor or Secure Partition Manager. > > + 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. > OK I need to explore this. > > + 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. > The idea must be to use the names as is from the spec. > What happens on big.LITTLE? > AFAIU, we don't have notion of bL in KVM. > > + > > + 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. > Again this is from the spec listed under manifests for the partitions. This will let the KVM know to start the partition in Aarch32/64. > > + > > + 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. > I don't have full knowledge on the details, will let Will comment on this. > You didn't document using '#address-cells'. Really, I'd just make this a > fixed uint64 (if not 'reg'). > I was wondering the same as the format from spec must be fixed, checked and unfortunately it is not 🙁. -- Regards, Sudeep
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 +%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 <will@kernel.org> + +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 + +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]+$": + 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' + 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. + + exec-state: + description: The execution state in which to execute the partition. + oneOf: + - const: "AArch64" + - const: "AArch32" + + 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. + + 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 <will@kernel.org> + +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 + read-only; + }; + };