From: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Rob Herring <robh@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: xen: Add xen,scmi-devid property description for SCMI
Date: Wed, 16 Mar 2022 16:46:20 +0000 [thread overview]
Message-ID: <20220316164619.GA3489934@EPUAKYIW015D> (raw)
In-Reply-To: <Yie47a4lqXjVzgxI@robh.at.kernel.org>
On Tue, Mar 08, 2022 at 02:13:33PM -0600, Rob Herring wrote:
> On Mon, Mar 07, 2022 at 08:17:44AM +0000, Oleksii Moisieiev wrote:
> > Document xen,scmi-devid property for the devices, using SCMI protocol
> > to work with clocks/resets/power-domains etc. This property is intended
> > to set the device_id, which should be used to manage device permissions
> > in the Firmware. Device permissions management described in DEN 0056,
> > Section 4.2.2.10 [0].
>
> If device_id is a SCMI thing, how is it set for other platforms and
> bindings? With clocks or power-domains, the device_id is the cell value,
> right?
>
> Since we don't yet have a device assignment, security, or partitioning
> binding, you've come up with some Xen specific solution. Given I know
> multiple people want some sort of binding for this, I'm not going to
> accept anything short of a common binding addressing the various needs.
>
Hi Sudeep,
On your email from 3/4/2022 you wrote:
> The fact that we don't need this to be part of SCMI OSPM user bindings,
> it is not addressed and can be considered as a gap.
> + The reason I want to keep it xen specific at the moment as we had some
> plan to extended the device-id usage in the spec which hasn't progressed
> a bit(I must admit that before you ask), and this addition should not be
> obstruct that future development. If we align with what we define xen
> specific as part of $subject work, we can always define generic binding
> in the future and slowly make the other obsolete over the time.
IIUC you have some plans to provide device_id support to the device-tree
bindings from your side. Maybe we can discuss some of your plans here
and we can come up with the generic device-id binding?
So I will have something to base on in Xen.
Best regards,
Oleksii.
>
> > This property is used by Xen hypervisor, which works as trusted Agent, to
> > set permissions for the devices, passed-through to the Guest Domains,
> > which are non-trusted Agents. Trusted and non-trusted Agent terms described
> > in Section 4.1.1 [0].
> >
> > [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdAMXQYrn8$ [developer[.]arm[.]com]
> >
> > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > ---
> > .../bindings/firmware/xen,scmi-devid.yaml | 42 +++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> > new file mode 100644
> > index 000000000000..49dc9951b54d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> > @@ -0,0 +1,42 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2022 EPAM Systems.
> > +%YAML 1.2
> > +---
> > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/firmware/xen,scmi-devid.yaml*__;Iw!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdAPJC8yo3$ [devicetree[.]org]
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdADgb5MTo$ [devicetree[.]org]
> > +
> > +title: Xen SCMI (System Control and Management Interface) Device ID binding
> > +
> > +maintainers:
> > + - Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > +
> > +select: true
> > +
> > +description: |
> > + SCMI device_id property is intended to set the device id, needed to manage
> > + the device permissions via SCMI protocol in the firmware. The device_id
> > + should match device ids, defined in the firmware so the device permissions
> > + can be requested by sending BASE_SET_DEVICE_PERMISSIONS (see 4.2.2.10 of [0]).
> > +
> > + This property is used by Xen hypervisor to set the device permissions for
> > + the Guest Domains. Where Xen is trusted Agent and Guest Domains are
> > + non-trusted Agents.
> > +
> > + [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdAMXQYrn8$ [developer[.]arm[.]com]
> > +
> > +properties:
> > + xen,scmi-devid:
> > + description: Identifier of the device, matching device id, defined in
> > + the firmware.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > + - |
> > + ohci1: usb@ee0a0000 {
> > + /* ... */
> > + reg = <0xee0a0000 0x100>;
> > + xen,scmi-devid = <11>;
>
> This will cause validation errors unless xen,scmi-devid is listed or
> this schema is referenced in every possible device schema. That
> doesn't scale, but we don't really have a solution to that. For some
> common properties, the tools will add certain properties. If we
> come up with something common, we'll need to add it. Or we may
> need to come up with something more data driven where certain schemas
> are automatically added.
>
> Rob
>
> > + clocks = <&scmi_clock 4>;
> > + };
> > --
> > 2.27.0
> >
next prev parent reply other threads:[~2022-03-16 16:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 8:17 [PATCH v2 0/2] dt-bindings: xen: Add xen,scmi-devid parameter for Oleksii Moisieiev
2022-03-07 8:17 ` [PATCH v2 1/2] dt-bindings: Add vendor prefix for Xen hypervisor Oleksii Moisieiev
2022-03-07 23:30 ` Stefano Stabellini
2022-03-08 20:14 ` Rob Herring
2022-03-10 11:38 ` Oleksii Moisieiev
2022-03-10 17:20 ` Stefano Stabellini
2022-03-07 8:17 ` [PATCH v2 2/2] dt-bindings: xen: Add xen,scmi-devid property description for SCMI Oleksii Moisieiev
2022-03-07 23:38 ` Stefano Stabellini
2022-03-08 20:13 ` Rob Herring
2022-03-16 16:46 ` Oleksii Moisieiev [this message]
2022-03-16 18:59 ` Sudeep Holla
2022-03-18 23:53 ` Stefano Stabellini
2022-03-22 11:12 ` Sudeep Holla
2022-03-22 19:21 ` Oleksii Moisieiev
2022-03-23 10:54 ` Sudeep Holla
2022-03-28 8:52 ` Oleksii Moisieiev
2022-04-12 22:42 ` Stefano Stabellini
2022-04-22 17:59 ` Sudeep Holla
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=20220316164619.GA3489934@EPUAKYIW015D \
--to=oleksii_moisieiev@epam.com \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sstabellini@kernel.org \
--cc=sudeep.holla@arm.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox