From: Sudeep Holla <sudeep.holla@arm.com> To: Rob Herring <robh@kernel.org> Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, Trilok Soni <tsoni@codeaurora.org>, arve@android.com, Andrew Walbran <qwandor@google.com>, David Hartley <dhh@qti.qualcomm.com>, Achin Gupta <Achin.Gupta@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Jens Wiklander <jens.wiklander@linaro.org>, Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Subject: Re: [PATCH v3 1/7] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Date: Wed, 16 Dec 2020 12:24:08 +0000 [thread overview] Message-ID: <20201216122408.2fhubdyqm2ofpgc3@bogus> (raw) In-Reply-To: <20201214220107.GA2430387@robh.at.kernel.org> On Mon, Dec 14, 2020 at 04:01:07PM -0600, Rob Herring wrote: > On Fri, Dec 04, 2020 at 12:11:31PM +0000, Sudeep Holla wrote: > > Since the FF-A v1.0 specification doesn't list the UUID of all the > > partitions in the discovery API, we need to specify the UUID of the > > partitions that need to be accessed by drivers within the kernel. > > > > This binding to provide the list of partitions that kernel drivers > > may need to access. > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,ffa.yaml | 58 +++++++++++++++++++ > > 1 file changed, 58 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.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..a014a5801c34 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > > @@ -0,0 +1,58 @@ > > +# SPDX-License-Identifier: (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 (in-kernel users) > > + > > +maintainers: > > + - Sudeep Holla <sudeep.holla@arm.com> > > + > > +description: | > > + Firmware frameworks implementing partition according to the FF-A > > + specification defined by ARM document number ARM DEN 0077A ("Arm Firmware > > + Framework for Arm v8-A") [0], providing services to be used by other > > + partitions. > > + > > + [0] https://developer.arm.com/docs/den0077/latest > > + > > +properties: > > + $nodename: > > + const: ffa > > + > > + compatible: > > + oneOf: > > + - const: arm,ffa-1.0 > > + > > +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 > > UUIDs are actually a known thing in json-schema with 'format: uuid'. > The meta-schema will probably reject that, so we'll need to add support > to dtschema. Maybe it should be a new definition to reference. > Ah OK, I will try that and ask for help if I am stuck as I am still trying to learn these, not there yet 😄 > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + ffa { > > + compatible = "arm,ffa-1.0"; > > + > > + ffa_partition0 { > > + compatible = "arm,ffa-1.0-partition"; > > + uuid = "12345678-9abc-def0-1234-56789abcdef0"; > > + }; > > + }; > > This could all be simplified down to just a single property: > Thanks for the suggestion, I would love this to force spec authors to stop relying on DT and add whatever needed in future to the spec as part of discovery APIs. > arm,ffa-partitions = "12345678-9abc-def0-1234-56789abcdef0", > "12345678-9abc-def0-1234-56789abcdef1" > "12345678-9abc-def0-1234-56789abcdef2"; > > Obviously, that's not extensible, but do we need it to be? > I prefer if we don't, but I will run this through spec authors so that they are aware of what we will do in DT which means they *have* to incorporate any future needs into the spec discovery apis. Ah I forgot the spec author is cc-ed. @Achin please shout if you see issues with this approach. -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com> To: Rob Herring <robh@kernel.org> Cc: Trilok Soni <tsoni@codeaurora.org>, devicetree@vger.kernel.org, David Hartley <dhh@qti.qualcomm.com>, Andrew Walbran <qwandor@google.com>, Achin Gupta <Achin.Gupta@arm.com>, arve@android.com, Sudeep Holla <sudeep.holla@arm.com>, Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>, Jens Wiklander <jens.wiklander@linaro.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 1/7] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Date: Wed, 16 Dec 2020 12:24:08 +0000 [thread overview] Message-ID: <20201216122408.2fhubdyqm2ofpgc3@bogus> (raw) In-Reply-To: <20201214220107.GA2430387@robh.at.kernel.org> On Mon, Dec 14, 2020 at 04:01:07PM -0600, Rob Herring wrote: > On Fri, Dec 04, 2020 at 12:11:31PM +0000, Sudeep Holla wrote: > > Since the FF-A v1.0 specification doesn't list the UUID of all the > > partitions in the discovery API, we need to specify the UUID of the > > partitions that need to be accessed by drivers within the kernel. > > > > This binding to provide the list of partitions that kernel drivers > > may need to access. > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,ffa.yaml | 58 +++++++++++++++++++ > > 1 file changed, 58 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.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..a014a5801c34 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > > @@ -0,0 +1,58 @@ > > +# SPDX-License-Identifier: (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 (in-kernel users) > > + > > +maintainers: > > + - Sudeep Holla <sudeep.holla@arm.com> > > + > > +description: | > > + Firmware frameworks implementing partition according to the FF-A > > + specification defined by ARM document number ARM DEN 0077A ("Arm Firmware > > + Framework for Arm v8-A") [0], providing services to be used by other > > + partitions. > > + > > + [0] https://developer.arm.com/docs/den0077/latest > > + > > +properties: > > + $nodename: > > + const: ffa > > + > > + compatible: > > + oneOf: > > + - const: arm,ffa-1.0 > > + > > +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 > > UUIDs are actually a known thing in json-schema with 'format: uuid'. > The meta-schema will probably reject that, so we'll need to add support > to dtschema. Maybe it should be a new definition to reference. > Ah OK, I will try that and ask for help if I am stuck as I am still trying to learn these, not there yet 😄 > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + ffa { > > + compatible = "arm,ffa-1.0"; > > + > > + ffa_partition0 { > > + compatible = "arm,ffa-1.0-partition"; > > + uuid = "12345678-9abc-def0-1234-56789abcdef0"; > > + }; > > + }; > > This could all be simplified down to just a single property: > Thanks for the suggestion, I would love this to force spec authors to stop relying on DT and add whatever needed in future to the spec as part of discovery APIs. > arm,ffa-partitions = "12345678-9abc-def0-1234-56789abcdef0", > "12345678-9abc-def0-1234-56789abcdef1" > "12345678-9abc-def0-1234-56789abcdef2"; > > Obviously, that's not extensible, but do we need it to be? > I prefer if we don't, but I will run this through spec authors so that they are aware of what we will do in DT which means they *have* to incorporate any future needs into the spec discovery apis. Ah I forgot the spec author is cc-ed. @Achin please shout if you see issues with this approach. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-16 12:25 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-04 12:11 [PATCH v3 0/7] firmware: Add initial support for Arm FF-A Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-04 12:11 ` [PATCH v3 1/7] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-14 22:01 ` Rob Herring 2020-12-14 22:01 ` Rob Herring 2020-12-16 12:24 ` Sudeep Holla [this message] 2020-12-16 12:24 ` Sudeep Holla 2020-12-16 13:46 ` Jens Wiklander 2020-12-16 13:46 ` Jens Wiklander 2021-01-13 10:00 ` Sudeep Holla 2021-01-13 10:00 ` Sudeep Holla 2020-12-04 12:11 ` [PATCH v3 2/7] arm64: smccc: Add support for SMCCCv1.2 input/output registers Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-04 12:11 ` [PATCH v3 3/7] firmware: arm_ffa: Add initial FFA bus support for device enumeration Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-04 12:11 ` [PATCH v3 4/7] firmware: arm_ffa: Add initial Arm FFA driver support Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-04 12:11 ` [PATCH v3 5/7] firmware: arm_ffa: Add support for SMCCC as transport to FFA driver Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-04 12:11 ` [PATCH v3 6/7] firmware: arm_ffa: Setup in-kernel users of FFA partitions Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-07 12:30 ` Jens Wiklander 2020-12-07 12:30 ` Jens Wiklander 2021-01-13 9:22 ` Sudeep Holla 2021-01-13 9:22 ` Sudeep Holla 2020-12-11 10:45 ` Jens Wiklander 2020-12-11 10:45 ` Jens Wiklander 2020-12-11 10:59 ` Jens Wiklander 2020-12-11 10:59 ` Jens Wiklander 2021-01-13 9:44 ` Sudeep Holla 2021-01-13 9:44 ` Sudeep Holla 2021-01-13 12:30 ` Jens Wiklander 2021-01-13 12:30 ` Jens Wiklander 2021-01-13 13:58 ` Achin Gupta 2021-01-13 13:58 ` Achin Gupta 2021-01-13 17:20 ` Sudeep Holla 2021-01-13 17:20 ` Sudeep Holla 2021-01-14 6:48 ` Jens Wiklander 2021-01-14 6:48 ` Jens Wiklander 2021-01-12 18:04 ` Sudeep Holla 2021-01-12 18:04 ` Sudeep Holla 2021-01-13 7:10 ` Jens Wiklander 2021-01-13 7:10 ` Jens Wiklander 2020-12-04 12:11 ` [PATCH v3 7/7] firmware: arm_ffa: Add support for MEM_* interfaces Sudeep Holla 2020-12-04 12:11 ` Sudeep Holla 2020-12-11 10:54 ` Jens Wiklander 2020-12-11 10:54 ` Jens Wiklander
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201216122408.2fhubdyqm2ofpgc3@bogus \ --to=sudeep.holla@arm.com \ --cc=Achin.Gupta@arm.com \ --cc=arunachalam.ganapathy@arm.com \ --cc=arve@android.com \ --cc=devicetree@vger.kernel.org \ --cc=dhh@qti.qualcomm.com \ --cc=jens.wiklander@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=qwandor@google.com \ --cc=robh@kernel.org \ --cc=tsoni@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.