[PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Oleksii Moisieiev]

Introducing the domain controller provider/consumenr bindngs which allow to
divided system on chip into multiple domains that can be used to select
by who hardware blocks could be accessed.
A domain could be a cluster of CPUs, a group of hardware blocks or the
set of devices, passed-through to the Guest in the virtualized systems.

Device controllers are typically used to set the permissions of the hardware
block. The contents of the domain configuration properties are defined by the
binding for the individual domain controller device.

The device controller conception in the virtualized systems is to set
the device configuration for SCMI (System Control and Management
Interface) which controls clocks/power-domains/resets etc from the
Firmware. This configuratio sets the device_id to set the device permissions
for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
determine device_id is not covered by the specification.
Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
Given parameter should set the device_id, needed to set device
permissions in the Firmware.
This property is used by trusted Agent (which is hypervisor in our case)
to set permissions for the devices, passed-through to the non-trusted
Agents. Trusted Agent will use device-perms to set the Device
permissions for the Firmware (See Section 4.2.2.10 [0] for details).
Agents concept is described in Section 4.2.1 [0].

Domains in Device-tree node example:
usb@e6590000
{
    domain-0 = <&scmi 19>; //Set domain id 19 to usb node
    clocks = <&scmi_clock 3>, <&scmi_clock 2>;
    resets = <&scmi_reset 10>, <&scmi_reset 9>;
    power-domains = <&scmi_power 0>;
};

&scmi {
    #domain-cells = <1>;
}

All mentioned bindings are going to be processed by XEN SCMI mediator
feature, which is responsible to redirect SCMI calls from guests to the
firmware, and not going be passed to the guests.

Domain-controller provider/consumenr concept was taken from the bus
controller framework patch series, provided in the following thread:
[1].

I think we can cooperate with the bus controller framework developers
and produce the common binding, which will fit the requirements of both
features

Also, I think that binding can also be used for STM32 ETZPC bus
controller feature, proposed in the following thread: [2].

Looking forward for your thoughts and ideas.

[0] https://developer.arm.com/documentation/den0056/latest
[1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/
[2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/

---
Changes v1 -> V2:
   - update parameter name, made it xen-specific
   - add xen vendor bindings

Changes V2 -> V3:
   - update parameter name, make it generic
   - update parameter format, add link to controller
   - do not include xen vendor bindings as already upstreamed

Changes V3 -> V4:
   - introduce domain controller provider/consumer device tree bindings
   - making scmi node to act as domain controller provider when the
     device permissions should be configured
---

Oleksii Moisieiev (2):
  dt-bindings: Document common device controller bindings
  dt-bindings: Update scmi node description

 .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
 .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
 2 files changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml

-- 
2.27.0

[PATCH v4 2/2] dt-bindings: Update scmi node description

[Oleksii Moisieiev]

Add '#domain-cells' property description to the scmi node.
This property makes scmi node as domain controller provider, which allows
consumers to provide scmi node with the device_ids of the devices, which are
using scmi protocols to control clocks/resets/power-domains etc.
The device_ids could be used to set the device permissions for the
Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
Device permissions management described in DEN 0056, Section 4.2.2.10 [0].

For SCMI this property is used by Trusted Agent to set the device permissions
for the Non-Trusted Agents.
Trusted and non-trusted Agent terms described in Section 4.1.1 [0].

[0] https://developer.arm.com/documentation/den0056/latest

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
---
Changes v1 -> V2:
   - update parameter name, made it xen-specific
   - add xen vendor bindings

Changes V2 -> V3:
   - update parameter name, make it generic
   - update parameter format, add link to controller
   - do not include xen vendor bindings as already upstreamed

Changes V3 -> V4:
   - introduce domain controller provider/consumer device tree bindings
   - making scmi node to act as domain controller provider when the
     device permissions should be configured
---
 .../bindings/firmware/arm,scmi.yaml           | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 5c4c6782e052..89589ed81b4e 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -78,6 +78,14 @@ properties:
   '#size-cells':
     const: 0
 
+  '#domain-cells':
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Number of cells in a domain controller specifier.
+      Set const to 1 here for nodes providing the device id, needed for
+      the BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
+    const: 1
+
   arm,smc-id:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
@@ -344,4 +352,21 @@ examples:
         };
     };
 
+  - |
+    firmware {
+        scmi_link: scmi {
+            compatible = "arm,scmi-smc";
+            shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>;
+            arm,smc-id = <0xc3000001>;
+
+            #address-cells = <1>;
+            #size-cells = <0>;
+            #domain-cells = <1>;
+        };
+    };
+
+    foo@0 {
+      reg = <0x0 0x10>;
+      domain-0 = <&scmi_link 1>;
+    };
 ...
-- 
2.27.0

[PATCH v4 1/2] dt-bindings: Document common device controller bindings

[Oleksii Moisieiev]

Introducing of the common device controller bindings for the controller
provider and consumer devices. Those bindings are intended to allow
divided system on chip into muliple domains, that can be used to
configure hardware permissions.

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
---
 .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml

diff --git a/Documentation/devicetree/bindings/domains/domain-controller.yaml b/Documentation/devicetree/bindings/domains/domain-controller.yaml
new file mode 100644
index 000000000000..377fdf0c21fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/domains/domain-controller.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/domains/domain-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Domain Controller bindings
+
+maintainers:
+  - Oleksii Moisieiev <oleksii_moisieiev@epam.com>
+
+description: |+
+  Common Domains Controller bindings properties
+
+  Domain controllers allow to divided system on chip into multiple domains
+  that can be used to select by who hardware blocks could be accessed.
+  A domain could be a cluster of CPUs (or coprocessors), a range of addresses
+  or a group of hardware blocks.
+
+  This device tree bindings can be used to bind domain consumer devices with
+  their domains provided by domain controllers. Domain controller provider can
+  be represened by any node in the device tree and can provide one or more
+  configuration parameters, needed to control parameters of the consumer
+  device. A consumer node can refer to the provider by phandle and a set of
+  phandle arguments, specified by '#domain-cells' property in the device
+  controller provider node.
+
+  Device controllers are typically used to set the permissions of the hardware
+  block. The contents of the domain configuration properties are defined by the
+  binding for the individual domain controller device.
+
+  Each node can be a consumer for the several providers. The first
+  configuration 'domain-0' or the one named 'default' is applied before probing
+  the device itself.
+
+# always select the core schema
+select: true
+
+properties:
+  '#domain-cells':
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Number of cells in a domain controller specifier;
+      Can be any value as specified by device tree binding documentation
+      of a particular provider.
+
+  domain-names:
+    $ref: '/schemas/types.yaml#/definitions/string-array'
+    maxItems: 9
+    description:
+      A list of domain name string, sorted in the same order as domain-X
+      properties. Consumer drivers will use domain-names to match with
+      existing domain specifiers.
+
+patternProperties:
+  "domain-[0-9]":
+    $ref: "/schemas/types.yaml#/definitions/phandle-array"
+    description:
+      A list of domain controller specifiers, as defined by the bindings of
+      the domain controller provider.
+
+additionalProperties: true
+
+examples:
+  - |
+    ctrl0: ctrl@100 {
+        reg = <0x100 0x10>;
+        #domain-cells = <2>;
+    };
+
+    ctrl1: ctrl@110 {
+        reg = <0x110 0x10>;
+        #domain-cells = <3>;
+    };
+
+    foo@0 {
+        reg = <0x0 0x1>;
+        domains-names = "default", "unbind";
+        domain-0 = <&ctrl0 1 2>, <&ctrl1 3 4 5>;
+        domain-1 = <&ctrl0 6 7>, <&ctrl1 8 9 0>;
+    };
-- 
2.27.0

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Linus Walleij]

On Thu, Jul 7, 2022 at 12:26 PM Oleksii Moisieiev
<Oleksii_Moisieiev@epam.com> wrote:

> Looking forward for your thoughts and ideas.

I think this looks good and is exactly what Benjamin's (stalled) patch
set needs.
We have two independent hardware pieces needing the same type
of domain sectioning.

I am just worried that no-one at ST is working on this anymore, Benjamin
is not working at ST anymore, he's at Collabora. (Changed the CC.)

Yours,
Linus Walleij

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Rob Herring]

On Thu, Jul 07, 2022 at 10:25:08AM +0000, Oleksii Moisieiev wrote:
> Introducing the domain controller provider/consumenr bindngs which allow to
> divided system on chip into multiple domains that can be used to select
> by who hardware blocks could be accessed.
> A domain could be a cluster of CPUs, a group of hardware blocks or the
> set of devices, passed-through to the Guest in the virtualized systems.

'domain' is entirely to ambiguous. We have clock domains, power domains, 
interrupt domains, etc. already. This needs to be specific about what is 
controlled/provided.

> 
> Device controllers are typically used to set the permissions of the hardware
> block. The contents of the domain configuration properties are defined by the
> binding for the individual domain controller device.
> 
> The device controller conception in the virtualized systems is to set
> the device configuration for SCMI (System Control and Management
> Interface) which controls clocks/power-domains/resets etc from the
> Firmware. This configuratio sets the device_id to set the device permissions
> for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
> There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> determine device_id is not covered by the specification.
> Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> Given parameter should set the device_id, needed to set device
> permissions in the Firmware.
> This property is used by trusted Agent (which is hypervisor in our case)
> to set permissions for the devices, passed-through to the non-trusted
> Agents. Trusted Agent will use device-perms to set the Device
> permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> Agents concept is described in Section 4.2.1 [0].
> 
> Domains in Device-tree node example:
> usb@e6590000
> {
>     domain-0 = <&scmi 19>; //Set domain id 19 to usb node

Don't use this pinctrl construct with a number suffix. That was entirely 
because 1 pinctrl entry needed to reference an arbitrary number of 
nodes. Follow the standard producer/consumer pattern where each entry is 
a phandle with arg cells. You've mostly done that, but we don't need 
'domain-0', 'domain-1', etc.

>     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
>     resets = <&scmi_reset 10>, <&scmi_reset 9>;
>     power-domains = <&scmi_power 0>;
> };
> 
> &scmi {
>     #domain-cells = <1>;
> }
> 
> All mentioned bindings are going to be processed by XEN SCMI mediator
> feature, which is responsible to redirect SCMI calls from guests to the
> firmware, and not going be passed to the guests.
> 
> Domain-controller provider/consumenr concept was taken from the bus
> controller framework patch series, provided in the following thread:
> [1].
> 
> I think we can cooperate with the bus controller framework developers
> and produce the common binding, which will fit the requirements of both
> features
> 
> Also, I think that binding can also be used for STM32 ETZPC bus
> controller feature, proposed in the following thread: [2].

Hopefully someone speaks up. If not, then rejecting past proposals must 
have been the right decision. Must not really have been needed...

Rob

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Linus Walleij]

On Wed, Jul 20, 2022 at 11:32 PM Rob Herring <robh@kernel.org> wrote:
> On Thu, Jul 07, 2022 at 10:25:08AM +0000, Oleksii Moisieiev wrote:
> > Introducing the domain controller provider/consumenr bindngs which allow to
> > divided system on chip into multiple domains that can be used to select
> > by who hardware blocks could be accessed.
> > A domain could be a cluster of CPUs, a group of hardware blocks or the
> > set of devices, passed-through to the Guest in the virtualized systems.
>
> 'domain' is entirely to ambiguous. We have clock domains, power domains,
> interrupt domains, etc. already. This needs to be specific about what is
> controlled/provided.

Good point.

This should be something like bus-domain, as it controls what the bus
can access.

Yours,
Linus Walleij

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Ahmad Fatoum]

Hello Oleksii,

On 07.07.22 12:25, Oleksii Moisieiev wrote:
> Introducing the domain controller provider/consumenr bindngs which allow to
> divided system on chip into multiple domains that can be used to select
> by who hardware blocks could be accessed.
> A domain could be a cluster of CPUs, a group of hardware blocks or the
> set of devices, passed-through to the Guest in the virtualized systems.
> 
> Device controllers are typically used to set the permissions of the hardware
> block. The contents of the domain configuration properties are defined by the
> binding for the individual domain controller device.
> 
> The device controller conception in the virtualized systems is to set
> the device configuration for SCMI (System Control and Management
> Interface) which controls clocks/power-domains/resets etc from the
> Firmware. This configuratio sets the device_id to set the device permissions
> for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
> There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> determine device_id is not covered by the specification.
> Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> Given parameter should set the device_id, needed to set device
> permissions in the Firmware.
> This property is used by trusted Agent (which is hypervisor in our case)
> to set permissions for the devices, passed-through to the non-trusted
> Agents. Trusted Agent will use device-perms to set the Device
> permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> Agents concept is described in Section 4.2.1 [0].
> 
> Domains in Device-tree node example:
> usb@e6590000
> {
>     domain-0 = <&scmi 19>; //Set domain id 19 to usb node
>     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
>     resets = <&scmi_reset 10>, <&scmi_reset 9>;
>     power-domains = <&scmi_power 0>;
> };
> 
> &scmi {
>     #domain-cells = <1>;
> }
> 
> All mentioned bindings are going to be processed by XEN SCMI mediator
> feature, which is responsible to redirect SCMI calls from guests to the
> firmware, and not going be passed to the guests.
> 
> Domain-controller provider/consumenr concept was taken from the bus
> controller framework patch series, provided in the following thread:
> [1].

I also was inspired by Benjamin's series to draft up a binding, but for a slightly
different problem: Some SoCs like the i.MX8MP have a great deal of variation
in which IPs are actually available. After factory testing, fuses are burnt
to describe which IPs are available and as the upstream DT only describes
the full featured SoCs, either board DT or bootloader is expected to turn
off the device that are unavailable.

What I came up with as a binding for the bootloader to guide its fixup
looks very similar to what you have:

feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
    feature-controller;
    feature-cells = <1>;
};

&vpu_g1 {
    features-gates = <&feat IMX8MP_VPU>;
};

The OCOTP driver would see that it has a feature-controller property and register
a callback with a feature controller framework that checks whether a device
is available. barebox, that I implemented this binding for, would walk
the kernel device tree on boot looking for the feature-gates property and then
disable/delete nodes as indicated without having to write any SoC specific code
and especially without hardcoding node names and hierarchies, which is quite brittle.

There was a previous attempt at defining a binding for this, but Rob's NAK
mentioned that a solution should cover both cases:

 https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/

Having implemented nearly the same binding as what you describe, I obviously like your
patch. Only thing I think that should be changed is the naming. A domain doesn't
really describe this gated-by-fuses scenario I have. Calling it feature-gates
instead OTOH makes sense for both your and my use case. Same goes for the documentation
that could be worded more generically. I am open to other suggestions of course. :-)

Also a general gpio-controller like property would be nice. It would allow drivers
to easily check whether they are supposed to register a domain/feature controller.
For devices like yours where a dedicated device node represents the domain controller,
it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
that, but I think a dedicated property may be better.

Let me know what you think and thanks for working on this!

Cheers,
Ahmad


> 
> I think we can cooperate with the bus controller framework developers
> and produce the common binding, which will fit the requirements of both
> features
> 
> Also, I think that binding can also be used for STM32 ETZPC bus
> controller feature, proposed in the following thread: [2].
> 
> Looking forward for your thoughts and ideas.
> 
> [0] https://developer.arm.com/documentation/den0056/latest
> [1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/
> [2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/
> 
> ---
> Changes v1 -> V2:
>    - update parameter name, made it xen-specific
>    - add xen vendor bindings
> 
> Changes V2 -> V3:
>    - update parameter name, make it generic
>    - update parameter format, add link to controller
>    - do not include xen vendor bindings as already upstreamed
> 
> Changes V3 -> V4:
>    - introduce domain controller provider/consumer device tree bindings
>    - making scmi node to act as domain controller provider when the
>      device permissions should be configured
> ---
> 
> Oleksii Moisieiev (2):
>   dt-bindings: Document common device controller bindings
>   dt-bindings: Update scmi node description
> 
>  .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
>  .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
>  2 files changed, 105 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

RE: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Loic PALLARDY]

Hello,


ST Restricted

> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Monday, August 15, 2022 6:37 PM
> To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>; robh+dt@kernel.org
> Cc: mcoquelin.stm32@gmail.com; Alexandre TORGUE
> <alexandre.torgue@st.com>; linus.walleij@linaro.org;
> gregkh@linuxfoundation.org; devicetree@vger.kernel.org; tomase@xilinx.com;
> Benjamin Gaignard <benjamin.gaignard@collabora.com>; broonie@kernel.org;
> arnd@arndb.de; shawnguo@kernel.org; fabio.estevam@nxp.com; Loic
> PALLARDY <loic.pallardy@st.com>; mark.rutland@arm.com; Sudeep Holla
> <sudeep.holla@arm.com>; Cristian Marussi <cristian.marussi@arm.com>;
> Stefano Stabellini <sstabellini@kernel.org>; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Peng Fan (OSS)
> <peng.fan@oss.nxp.com>
> Subject: Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller
> 
> Hello Oleksii,
> 
> On 07.07.22 12:25, Oleksii Moisieiev wrote:
> > Introducing the domain controller provider/consumenr bindngs which allow
> to
> > divided system on chip into multiple domains that can be used to select
> > by who hardware blocks could be accessed.
> > A domain could be a cluster of CPUs, a group of hardware blocks or the
> > set of devices, passed-through to the Guest in the virtualized systems.
> >
> > Device controllers are typically used to set the permissions of the hardware
> > block. The contents of the domain configuration properties are defined by the
> > binding for the individual domain controller device.
> >
> > The device controller conception in the virtualized systems is to set
> > the device configuration for SCMI (System Control and Management
> > Interface) which controls clocks/power-domains/resets etc from the
> > Firmware. This configuratio sets the device_id to set the device permissions
> > for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see
> 4.2.2.10 of [0]).
> > There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> > determine device_id is not covered by the specification.
> > Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> > Given parameter should set the device_id, needed to set device
> > permissions in the Firmware.
> > This property is used by trusted Agent (which is hypervisor in our case)
> > to set permissions for the devices, passed-through to the non-trusted
> > Agents. Trusted Agent will use device-perms to set the Device
> > permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> > Agents concept is described in Section 4.2.1 [0].
> >
> > Domains in Device-tree node example:
> > usb@e6590000
> > {
> >     domain-0 = <&scmi 19>; //Set domain id 19 to usb node
> >     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
> >     resets = <&scmi_reset 10>, <&scmi_reset 9>;
> >     power-domains = <&scmi_power 0>;
> > };
> >
> > &scmi {
> >     #domain-cells = <1>;
> > }
> >
> > All mentioned bindings are going to be processed by XEN SCMI mediator
> > feature, which is responsible to redirect SCMI calls from guests to the
> > firmware, and not going be passed to the guests.
> >
> > Domain-controller provider/consumenr concept was taken from the bus
> > controller framework patch series, provided in the following thread:
> > [1].
> 
> I also was inspired by Benjamin's series to draft up a binding, but for a slightly
> different problem: Some SoCs like the i.MX8MP have a great deal of variation
> in which IPs are actually available. After factory testing, fuses are burnt
> to describe which IPs are available and as the upstream DT only describes
> the full featured SoCs, either board DT or bootloader is expected to turn
> off the device that are unavailable.
> 
> What I came up with as a binding for the bootloader to guide its fixup
> looks very similar to what you have:
> 
> feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
>     feature-controller;
>     feature-cells = <1>;
> };
> 
> &vpu_g1 {
>     features-gates = <&feat IMX8MP_VPU>;
> };
> 
> The OCOTP driver would see that it has a feature-controller property and
> register
> a callback with a feature controller framework that checks whether a device
> is available. barebox, that I implemented this binding for, would walk
> the kernel device tree on boot looking for the feature-gates property and then
> disable/delete nodes as indicated without having to write any SoC specific code
> and especially without hardcoding node names and hierarchies, which is quite
> brittle.
> 
> There was a previous attempt at defining a binding for this, but Rob's NAK
> mentioned that a solution should cover both cases:
> 
>  https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/
> 
> Having implemented nearly the same binding as what you describe, I obviously
> like your
> patch. Only thing I think that should be changed is the naming. A domain doesn't
> really describe this gated-by-fuses scenario I have. Calling it feature-gates
> instead OTOH makes sense for both your and my use case. Same goes for the
> documentation
> that could be worded more generically. I am open to other suggestions of
> course. :-)

Issue looks the same as the initial one, how to guarantee Linux kernel won't try to access to
resources protected by firewall or OTP.

Initial proposal from Benjamin was NAK for different reasons and DT bindings were also
discussed during system DT calls without any agreement at the end.
Today we have decided to implement a platform bus to check access like proposed by Greg [1].
Indeed, a new framework was rejected at the time being.
The main difference compared to [2] is that bus identifies peripheral thanks to its base address "reg" and 
then verifies associated access properties before probing or not device.
It was a proposal from Rob we discussed during a system DT call to avoid an additional binding.

We are late to send an update because we are also working on OP-TEE and U-Boot to verify
the approach and be sure we can cover our specific SoC cases with this solution.

Regards,
Loic

[1] https://patchwork.ozlabs.org/project/devicetree-bindings/cover/20200128153806.7780-1-benjamin.gaignard@st.com/
[2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/

> 
> Also a general gpio-controller like property would be nice. It would allow drivers
> to easily check whether they are supposed to register a domain/feature
> controller.
> For devices like yours where a dedicated device node represents the domain
> controller,
> it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
> that, but I think a dedicated property may be better.
> 
> Let me know what you think and thanks for working on this!
> 
> Cheers,
> Ahmad
> 
> 
> >
> > I think we can cooperate with the bus controller framework developers
> > and produce the common binding, which will fit the requirements of both
> > features
> >
> > Also, I think that binding can also be used for STM32 ETZPC bus
> > controller feature, proposed in the following thread: [2].
> >
> > Looking forward for your thoughts and ideas.
> >
> > [0] https://developer.arm.com/documentation/den0056/latest
> > [1] https://lore.kernel.org/all/20190318100605.29120-1-
> benjamin.gaignard@st.com/
> > [2] https://lore.kernel.org/all/20200701132523.32533-1-
> benjamin.gaignard@st.com/
> >
> > ---
> > Changes v1 -> V2:
> >    - update parameter name, made it xen-specific
> >    - add xen vendor bindings
> >
> > Changes V2 -> V3:
> >    - update parameter name, make it generic
> >    - update parameter format, add link to controller
> >    - do not include xen vendor bindings as already upstreamed
> >
> > Changes V3 -> V4:
> >    - introduce domain controller provider/consumer device tree bindings
> >    - making scmi node to act as domain controller provider when the
> >      device permissions should be configured
> > ---
> >
> > Oleksii Moisieiev (2):
> >   dt-bindings: Document common device controller bindings
> >   dt-bindings: Update scmi node description
> >
> >  .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
> >  .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
> >  2 files changed, 105 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/domains/domain-
> controller.yaml
> >
> 
> 
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Oleksii Moisieiev]

On Wed, Aug 17, 2022 at 07:09:57AM +0000, Loic PALLARDY wrote:
> Hello,
> 
> 
> ST Restricted
> 
> > -----Original Message-----
> > From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > Sent: Monday, August 15, 2022 6:37 PM
> > To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>; robh+dt@kernel.org
> > Cc: mcoquelin.stm32@gmail.com; Alexandre TORGUE
> > <alexandre.torgue@st.com>; linus.walleij@linaro.org;
> > gregkh@linuxfoundation.org; devicetree@vger.kernel.org; tomase@xilinx.com;
> > Benjamin Gaignard <benjamin.gaignard@collabora.com>; broonie@kernel.org;
> > arnd@arndb.de; shawnguo@kernel.org; fabio.estevam@nxp.com; Loic
> > PALLARDY <loic.pallardy@st.com>; mark.rutland@arm.com; Sudeep Holla
> > <sudeep.holla@arm.com>; Cristian Marussi <cristian.marussi@arm.com>;
> > Stefano Stabellini <sstabellini@kernel.org>; linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; Peng Fan (OSS)
> > <peng.fan@oss.nxp.com>
> > Subject: Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller
> > 
> > Hello Oleksii,
> > 
> > On 07.07.22 12:25, Oleksii Moisieiev wrote:
> > > Introducing the domain controller provider/consumenr bindngs which allow
> > to
> > > divided system on chip into multiple domains that can be used to select
> > > by who hardware blocks could be accessed.
> > > A domain could be a cluster of CPUs, a group of hardware blocks or the
> > > set of devices, passed-through to the Guest in the virtualized systems.
> > >
> > > Device controllers are typically used to set the permissions of the hardware
> > > block. The contents of the domain configuration properties are defined by the
> > > binding for the individual domain controller device.
> > >
> > > The device controller conception in the virtualized systems is to set
> > > the device configuration for SCMI (System Control and Management
> > > Interface) which controls clocks/power-domains/resets etc from the
> > > Firmware. This configuratio sets the device_id to set the device permissions
> > > for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see
> > 4.2.2.10 of [0]).
> > > There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> > > determine device_id is not covered by the specification.
> > > Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> > > Given parameter should set the device_id, needed to set device
> > > permissions in the Firmware.
> > > This property is used by trusted Agent (which is hypervisor in our case)
> > > to set permissions for the devices, passed-through to the non-trusted
> > > Agents. Trusted Agent will use device-perms to set the Device
> > > permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> > > Agents concept is described in Section 4.2.1 [0].
> > >
> > > Domains in Device-tree node example:
> > > usb@e6590000
> > > {
> > >     domain-0 = <&scmi 19>; //Set domain id 19 to usb node
> > >     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
> > >     resets = <&scmi_reset 10>, <&scmi_reset 9>;
> > >     power-domains = <&scmi_power 0>;
> > > };
> > >
> > > &scmi {
> > >     #domain-cells = <1>;
> > > }
> > >
> > > All mentioned bindings are going to be processed by XEN SCMI mediator
> > > feature, which is responsible to redirect SCMI calls from guests to the
> > > firmware, and not going be passed to the guests.
> > >
> > > Domain-controller provider/consumenr concept was taken from the bus
> > > controller framework patch series, provided in the following thread:
> > > [1].
> > 
> > I also was inspired by Benjamin's series to draft up a binding, but for a slightly
> > different problem: Some SoCs like the i.MX8MP have a great deal of variation
> > in which IPs are actually available. After factory testing, fuses are burnt
> > to describe which IPs are available and as the upstream DT only describes
> > the full featured SoCs, either board DT or bootloader is expected to turn
> > off the device that are unavailable.
> > 
> > What I came up with as a binding for the bootloader to guide its fixup
> > looks very similar to what you have:
> > 
> > feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
> >     feature-controller;
> >     feature-cells = <1>;
> > };
> > 
> > &vpu_g1 {
> >     features-gates = <&feat IMX8MP_VPU>;
> > };
> > 
> > The OCOTP driver would see that it has a feature-controller property and
> > register
> > a callback with a feature controller framework that checks whether a device
> > is available. barebox, that I implemented this binding for, would walk
> > the kernel device tree on boot looking for the feature-gates property and then
> > disable/delete nodes as indicated without having to write any SoC specific code
> > and especially without hardcoding node names and hierarchies, which is quite
> > brittle.
> > 
> > There was a previous attempt at defining a binding for this, but Rob's NAK
> > mentioned that a solution should cover both cases:
> > 
> >  https://urldefense.com/v3/__https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ7OSmC7HQ$  [lore[.]kernel[.]org]
> > 
> > Having implemented nearly the same binding as what you describe, I obviously
> > like your
> > patch. Only thing I think that should be changed is the naming. A domain doesn't
> > really describe this gated-by-fuses scenario I have. Calling it feature-gates
> > instead OTOH makes sense for both your and my use case. Same goes for the
> > documentation
> > that could be worded more generically. I am open to other suggestions of
> > course. :-)
> 
> Issue looks the same as the initial one, how to guarantee Linux kernel won't try to access to
> resources protected by firewall or OTP.
> 
> Initial proposal from Benjamin was NAK for different reasons and DT bindings were also
> discussed during system DT calls without any agreement at the end.
> Today we have decided to implement a platform bus to check access like proposed by Greg [1].
> Indeed, a new framework was rejected at the time being.
> The main difference compared to [2] is that bus identifies peripheral thanks to its base address "reg" and 
> then verifies associated access properties before probing or not device.
> It was a proposal from Rob we discussed during a system DT call to avoid an additional binding.
> 

Hi Loic,

I also thought about the device identification, based on it's base
address "reg", but the problem is that on different platforms regs
should be different. My suggestion is to make common binding, which
allows to identify the devices or set the device parameters and then use
this information for driver specific purposes. Those values should be
common to all platforms and there is no need to write translation tables
regs -> device_id for each platform. Also values can be potentially
used to set some device parameters, not just as device identifiers.

Best regards,
Oleskii.

> We are late to send an update because we are also working on OP-TEE and U-Boot to verify
> the approach and be sure we can cover our specific SoC cases with this solution.
> 
> Regards,
> Loic
> 
> [1] https://urldefense.com/v3/__https://patchwork.ozlabs.org/project/devicetree-bindings/cover/20200128153806.7780-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ5QBPMO3g$  [patchwork[.]ozlabs[.]org]
> [2] https://urldefense.com/v3/__https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ5e94Xj5w$  [lore[.]kernel[.]org]
> 
> > 
> > Also a general gpio-controller like property would be nice. It would allow drivers
> > to easily check whether they are supposed to register a domain/feature
> > controller.
> > For devices like yours where a dedicated device node represents the domain
> > controller,
> > it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
> > that, but I think a dedicated property may be better.
> > 
> > Let me know what you think and thanks for working on this!
> > 
> > Cheers,
> > Ahmad
> > 
> > 
> > >
> > > I think we can cooperate with the bus controller framework developers
> > > and produce the common binding, which will fit the requirements of both
> > > features
> > >
> > > Also, I think that binding can also be used for STM32 ETZPC bus
> > > controller feature, proposed in the following thread: [2].
> > >
> > > Looking forward for your thoughts and ideas.
> > >
> > > [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ4PJTS54g$  [developer[.]arm[.]com]
> > > [1] https://urldefense.com/v3/__https://lore.kernel.org/all/20190318100605.29120-1-__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ60ZFPZKg$  [lore[.]kernel[.]org]
> > benjamin.gaignard@st.com/
> > > [2] https://urldefense.com/v3/__https://lore.kernel.org/all/20200701132523.32533-1-__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ4pcCPvwg$  [lore[.]kernel[.]org]
> > benjamin.gaignard@st.com/
> > >
> > > ---
> > > Changes v1 -> V2:
> > >    - update parameter name, made it xen-specific
> > >    - add xen vendor bindings
> > >
> > > Changes V2 -> V3:
> > >    - update parameter name, make it generic
> > >    - update parameter format, add link to controller
> > >    - do not include xen vendor bindings as already upstreamed
> > >
> > > Changes V3 -> V4:
> > >    - introduce domain controller provider/consumer device tree bindings
> > >    - making scmi node to act as domain controller provider when the
> > >      device permissions should be configured
> > > ---
> > >
> > > Oleksii Moisieiev (2):
> > >   dt-bindings: Document common device controller bindings
> > >   dt-bindings: Update scmi node description
> > >
> > >  .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
> > >  .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
> > >  2 files changed, 105 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/domains/domain-
> > controller.yaml
> > >
> > 
> > 
> > --
> > Pengutronix e.K.                           |                             |
> > Steuerwalder Str. 21                       | https://urldefense.com/v3/__http://www.pengutronix.de/__;!!GF_29dbcQIUBPA!xfDOoAXBRWNVG6S9o74w3BLqNOTamI_n0-lTb7WX_ZJo7ljnENiZE5FCXmDYTdGwGRyqj4c8dqLqsDurEZ4CWLnh6g$  [pengutronix[.]de]  |
> > 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Oleksii Moisieiev]

On Mon, Aug 15, 2022 at 06:37:23PM +0200, Ahmad Fatoum wrote:
> Hello Oleksii,
> 
> On 07.07.22 12:25, Oleksii Moisieiev wrote:
> > Introducing the domain controller provider/consumenr bindngs which allow to
> > divided system on chip into multiple domains that can be used to select
> > by who hardware blocks could be accessed.
> > A domain could be a cluster of CPUs, a group of hardware blocks or the
> > set of devices, passed-through to the Guest in the virtualized systems.
> > 
> > Device controllers are typically used to set the permissions of the hardware
> > block. The contents of the domain configuration properties are defined by the
> > binding for the individual domain controller device.
> > 
> > The device controller conception in the virtualized systems is to set
> > the device configuration for SCMI (System Control and Management
> > Interface) which controls clocks/power-domains/resets etc from the
> > Firmware. This configuratio sets the device_id to set the device permissions
> > for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
> > There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> > determine device_id is not covered by the specification.
> > Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> > Given parameter should set the device_id, needed to set device
> > permissions in the Firmware.
> > This property is used by trusted Agent (which is hypervisor in our case)
> > to set permissions for the devices, passed-through to the non-trusted
> > Agents. Trusted Agent will use device-perms to set the Device
> > permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> > Agents concept is described in Section 4.2.1 [0].
> > 
> > Domains in Device-tree node example:
> > usb@e6590000
> > {
> >     domain-0 = <&scmi 19>; //Set domain id 19 to usb node
> >     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
> >     resets = <&scmi_reset 10>, <&scmi_reset 9>;
> >     power-domains = <&scmi_power 0>;
> > };
> > 
> > &scmi {
> >     #domain-cells = <1>;
> > }
> > 
> > All mentioned bindings are going to be processed by XEN SCMI mediator
> > feature, which is responsible to redirect SCMI calls from guests to the
> > firmware, and not going be passed to the guests.
> > 
> > Domain-controller provider/consumenr concept was taken from the bus
> > controller framework patch series, provided in the following thread:
> > [1].
> 
> I also was inspired by Benjamin's series to draft up a binding, but for a slightly
> different problem: Some SoCs like the i.MX8MP have a great deal of variation
> in which IPs are actually available. After factory testing, fuses are burnt
> to describe which IPs are available and as the upstream DT only describes
> the full featured SoCs, either board DT or bootloader is expected to turn
> off the device that are unavailable.
> 
> What I came up with as a binding for the bootloader to guide its fixup
> looks very similar to what you have:
> 
> feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
>     feature-controller;
>     feature-cells = <1>;
> };
> 
> &vpu_g1 {
>     features-gates = <&feat IMX8MP_VPU>;
> };
> 
> The OCOTP driver would see that it has a feature-controller property and register
> a callback with a feature controller framework that checks whether a device
> is available. barebox, that I implemented this binding for, would walk
> the kernel device tree on boot looking for the feature-gates property and then
> disable/delete nodes as indicated without having to write any SoC specific code
> and especially without hardcoding node names and hierarchies, which is quite brittle.
> 
> There was a previous attempt at defining a binding for this, but Rob's NAK
> mentioned that a solution should cover both cases:
> 
>  https://urldefense.com/v3/__https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzHFDBt_$  [lore[.]kernel[.]org]
> 
> Having implemented nearly the same binding as what you describe, I obviously like your
> patch. Only thing I think that should be changed is the naming. A domain doesn't
> really describe this gated-by-fuses scenario I have. Calling it feature-gates
> instead OTOH makes sense for both your and my use case. Same goes for the documentation
> that could be worded more generically. I am open to other suggestions of course. :-)
> 
> Also a general gpio-controller like property would be nice. It would allow drivers
> to easily check whether they are supposed to register a domain/feature controller.
> For devices like yours where a dedicated device node represents the domain controller,
> it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
> that, but I think a dedicated property may be better.
> 
> Let me know what you think and thanks for working on this!
> 
> Cheers,
> Ahmad
> 

Hello Ahmad,

I'm very happy that you are interested in my proposal. It will be great
if we produce common binding to suite both our requirements.
I agree that binding should be renamed, but I don't think feature-gates
name would fit my case.
IIUC both our cases requires different devices across the system to
provide some information to the controller device. This information
could be used to identify the devices later or to make some
controller-specific configuration. In this case I would prefer name
"device-feature" or "bus-domain", suggested by Linus Walleij.
Also I like your idea to add dedicated property. This will make bindings
more clear.
Summarizing all above, I would suggest the following names:

 feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
     device-feature-controller;
     device-feature-cells = <1>;
 };

 &vpu_g1 {
     device-features = <&feat IMX8MP_VPU>;
 };

What do you think about this?

Best regards,
Oleksii.

> 
> > 
> > I think we can cooperate with the bus controller framework developers
> > and produce the common binding, which will fit the requirements of both
> > features
> > 
> > Also, I think that binding can also be used for STM32 ETZPC bus
> > controller feature, proposed in the following thread: [2].
> > 
> > Looking forward for your thoughts and ideas.
> > 
> > [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH59KKjhc$  [developer[.]arm[.]com]
> > [1] https://urldefense.com/v3/__https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHy1kyyWZ$  [lore[.]kernel[.]org]
> > [2] https://urldefense.com/v3/__https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzVdVT4B$  [lore[.]kernel[.]org]
> > 
> > ---
> > Changes v1 -> V2:
> >    - update parameter name, made it xen-specific
> >    - add xen vendor bindings
> > 
> > Changes V2 -> V3:
> >    - update parameter name, make it generic
> >    - update parameter format, add link to controller
> >    - do not include xen vendor bindings as already upstreamed
> > 
> > Changes V3 -> V4:
> >    - introduce domain controller provider/consumer device tree bindings
> >    - making scmi node to act as domain controller provider when the
> >      device permissions should be configured
> > ---
> > 
> > Oleksii Moisieiev (2):
> >   dt-bindings: Document common device controller bindings
> >   dt-bindings: Update scmi node description
> > 
> >  .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
> >  .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
> >  2 files changed, 105 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml
> > 
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | https://urldefense.com/v3/__http://www.pengutronix.de/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH_HqFmwM$  [pengutronix[.]de]  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Ahmad Fatoum]

Hello Oleksii,

On 18.08.22 11:05, Oleksii Moisieiev wrote:
> On Mon, Aug 15, 2022 at 06:37:23PM +0200, Ahmad Fatoum wrote:
>> Hello Oleksii,
>>
>> On 07.07.22 12:25, Oleksii Moisieiev wrote:
>>> Introducing the domain controller provider/consumenr bindngs which allow to
>>> divided system on chip into multiple domains that can be used to select
>>> by who hardware blocks could be accessed.
>>> A domain could be a cluster of CPUs, a group of hardware blocks or the
>>> set of devices, passed-through to the Guest in the virtualized systems.
>>>
>>> Device controllers are typically used to set the permissions of the hardware
>>> block. The contents of the domain configuration properties are defined by the
>>> binding for the individual domain controller device.
>>>
>>> The device controller conception in the virtualized systems is to set
>>> the device configuration for SCMI (System Control and Management
>>> Interface) which controls clocks/power-domains/resets etc from the
>>> Firmware. This configuratio sets the device_id to set the device permissions
>>> for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
>>> There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
>>> determine device_id is not covered by the specification.
>>> Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
>>> Given parameter should set the device_id, needed to set device
>>> permissions in the Firmware.
>>> This property is used by trusted Agent (which is hypervisor in our case)
>>> to set permissions for the devices, passed-through to the non-trusted
>>> Agents. Trusted Agent will use device-perms to set the Device
>>> permissions for the Firmware (See Section 4.2.2.10 [0] for details).
>>> Agents concept is described in Section 4.2.1 [0].
>>>
>>> Domains in Device-tree node example:
>>> usb@e6590000
>>> {
>>>     domain-0 = <&scmi 19>; //Set domain id 19 to usb node
>>>     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
>>>     resets = <&scmi_reset 10>, <&scmi_reset 9>;
>>>     power-domains = <&scmi_power 0>;
>>> };
>>>
>>> &scmi {
>>>     #domain-cells = <1>;
>>> }
>>>
>>> All mentioned bindings are going to be processed by XEN SCMI mediator
>>> feature, which is responsible to redirect SCMI calls from guests to the
>>> firmware, and not going be passed to the guests.
>>>
>>> Domain-controller provider/consumenr concept was taken from the bus
>>> controller framework patch series, provided in the following thread:
>>> [1].
>>
>> I also was inspired by Benjamin's series to draft up a binding, but for a slightly
>> different problem: Some SoCs like the i.MX8MP have a great deal of variation
>> in which IPs are actually available. After factory testing, fuses are burnt
>> to describe which IPs are available and as the upstream DT only describes
>> the full featured SoCs, either board DT or bootloader is expected to turn
>> off the device that are unavailable.
>>
>> What I came up with as a binding for the bootloader to guide its fixup
>> looks very similar to what you have:
>>
>> feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
>>     feature-controller;
>>     feature-cells = <1>;
>> };
>>
>> &vpu_g1 {
>>     features-gates = <&feat IMX8MP_VPU>;
>> };
>>
>> The OCOTP driver would see that it has a feature-controller property and register
>> a callback with a feature controller framework that checks whether a device
>> is available. barebox, that I implemented this binding for, would walk
>> the kernel device tree on boot looking for the feature-gates property and then
>> disable/delete nodes as indicated without having to write any SoC specific code
>> and especially without hardcoding node names and hierarchies, which is quite brittle.
>>
>> There was a previous attempt at defining a binding for this, but Rob's NAK
>> mentioned that a solution should cover both cases:
>>
>>  https://urldefense.com/v3/__https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzHFDBt_$  [lore[.]kernel[.]org]
>>
>> Having implemented nearly the same binding as what you describe, I obviously like your
>> patch. Only thing I think that should be changed is the naming. A domain doesn't
>> really describe this gated-by-fuses scenario I have. Calling it feature-gates
>> instead OTOH makes sense for both your and my use case. Same goes for the documentation
>> that could be worded more generically. I am open to other suggestions of course. :-)
>>
>> Also a general gpio-controller like property would be nice. It would allow drivers
>> to easily check whether they are supposed to register a domain/feature controller.
>> For devices like yours where a dedicated device node represents the domain controller,
>> it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
>> that, but I think a dedicated property may be better.
>>
>> Let me know what you think and thanks for working on this!
>>
>> Cheers,
>> Ahmad
>>
> 
> Hello Ahmad,
> 
> I'm very happy that you are interested in my proposal. It will be great
> if we produce common binding to suite both our requirements.
> I agree that binding should be renamed, but I don't think feature-gates
> name would fit my case.
> IIUC both our cases requires different devices across the system to
> provide some information to the controller device. This information
> could be used to identify the devices later or to make some
> controller-specific configuration. In this case I would prefer name
> "device-feature" or "bus-domain", suggested by Linus Walleij.
> Also I like your idea to add dedicated property. This will make bindings
> more clear.
> Summarizing all above, I would suggest the following names:
> 
>  feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
>      device-feature-controller;
>      device-feature-cells = <1>;
>  };
> 
>  &vpu_g1 {
>      device-features = <&feat IMX8MP_VPU>;
>  };
> 
> What do you think about this?

Sorry for the late answer. Full plate before vacation :)

A device- prefix for device properties is kind of redundant IMO.
And [device-]features is somewhat ambiguous (it's not
a list of features of the device, but a list of features that
control the device). I see that gates might sounds a bit odd, how about
feature-domains, feature-domain-controller, #feature-domain-cells?

Cheers,
Ahmad

> 
> Best regards,
> Oleksii.
> 
>>
>>>
>>> I think we can cooperate with the bus controller framework developers
>>> and produce the common binding, which will fit the requirements of both
>>> features
>>>
>>> Also, I think that binding can also be used for STM32 ETZPC bus
>>> controller feature, proposed in the following thread: [2].
>>>
>>> Looking forward for your thoughts and ideas.
>>>
>>> [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH59KKjhc$  [developer[.]arm[.]com]
>>> [1] https://urldefense.com/v3/__https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHy1kyyWZ$  [lore[.]kernel[.]org]
>>> [2] https://urldefense.com/v3/__https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzVdVT4B$  [lore[.]kernel[.]org]
>>>
>>> ---
>>> Changes v1 -> V2:
>>>    - update parameter name, made it xen-specific
>>>    - add xen vendor bindings
>>>
>>> Changes V2 -> V3:
>>>    - update parameter name, make it generic
>>>    - update parameter format, add link to controller
>>>    - do not include xen vendor bindings as already upstreamed
>>>
>>> Changes V3 -> V4:
>>>    - introduce domain controller provider/consumer device tree bindings
>>>    - making scmi node to act as domain controller provider when the
>>>      device permissions should be configured
>>> ---
>>>
>>> Oleksii Moisieiev (2):
>>>   dt-bindings: Document common device controller bindings
>>>   dt-bindings: Update scmi node description
>>>
>>>  .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
>>>  .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
>>>  2 files changed, 105 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml
>>>
>>
>>
>> -- 
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       | https://urldefense.com/v3/__http://www.pengutronix.de/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH_HqFmwM$  [pengutronix[.]de]  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Oleksii Moisieiev]

On Tue, Aug 30, 2022 at 09:34:16AM +0200, Ahmad Fatoum wrote:
> Hello Oleksii,
> 
> On 18.08.22 11:05, Oleksii Moisieiev wrote:
> > On Mon, Aug 15, 2022 at 06:37:23PM +0200, Ahmad Fatoum wrote:
> >> Hello Oleksii,
> >>
> >> On 07.07.22 12:25, Oleksii Moisieiev wrote:
> >>> Introducing the domain controller provider/consumenr bindngs which allow to
> >>> divided system on chip into multiple domains that can be used to select
> >>> by who hardware blocks could be accessed.
> >>> A domain could be a cluster of CPUs, a group of hardware blocks or the
> >>> set of devices, passed-through to the Guest in the virtualized systems.
> >>>
> >>> Device controllers are typically used to set the permissions of the hardware
> >>> block. The contents of the domain configuration properties are defined by the
> >>> binding for the individual domain controller device.
> >>>
> >>> The device controller conception in the virtualized systems is to set
> >>> the device configuration for SCMI (System Control and Management
> >>> Interface) which controls clocks/power-domains/resets etc from the
> >>> Firmware. This configuratio sets the device_id to set the device permissions
> >>> for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
> >>> There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> >>> determine device_id is not covered by the specification.
> >>> Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> >>> Given parameter should set the device_id, needed to set device
> >>> permissions in the Firmware.
> >>> This property is used by trusted Agent (which is hypervisor in our case)
> >>> to set permissions for the devices, passed-through to the non-trusted
> >>> Agents. Trusted Agent will use device-perms to set the Device
> >>> permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> >>> Agents concept is described in Section 4.2.1 [0].
> >>>
> >>> Domains in Device-tree node example:
> >>> usb@e6590000
> >>> {
> >>>     domain-0 = <&scmi 19>; //Set domain id 19 to usb node
> >>>     clocks = <&scmi_clock 3>, <&scmi_clock 2>;
> >>>     resets = <&scmi_reset 10>, <&scmi_reset 9>;
> >>>     power-domains = <&scmi_power 0>;
> >>> };
> >>>
> >>> &scmi {
> >>>     #domain-cells = <1>;
> >>> }
> >>>
> >>> All mentioned bindings are going to be processed by XEN SCMI mediator
> >>> feature, which is responsible to redirect SCMI calls from guests to the
> >>> firmware, and not going be passed to the guests.
> >>>
> >>> Domain-controller provider/consumenr concept was taken from the bus
> >>> controller framework patch series, provided in the following thread:
> >>> [1].
> >>
> >> I also was inspired by Benjamin's series to draft up a binding, but for a slightly
> >> different problem: Some SoCs like the i.MX8MP have a great deal of variation
> >> in which IPs are actually available. After factory testing, fuses are burnt
> >> to describe which IPs are available and as the upstream DT only describes
> >> the full featured SoCs, either board DT or bootloader is expected to turn
> >> off the device that are unavailable.
> >>
> >> What I came up with as a binding for the bootloader to guide its fixup
> >> looks very similar to what you have:
> >>
> >> feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
> >>     feature-controller;
> >>     feature-cells = <1>;
> >> };
> >>
> >> &vpu_g1 {
> >>     features-gates = <&feat IMX8MP_VPU>;
> >> };
> >>
> >> The OCOTP driver would see that it has a feature-controller property and register
> >> a callback with a feature controller framework that checks whether a device
> >> is available. barebox, that I implemented this binding for, would walk
> >> the kernel device tree on boot looking for the feature-gates property and then
> >> disable/delete nodes as indicated without having to write any SoC specific code
> >> and especially without hardcoding node names and hierarchies, which is quite brittle.
> >>
> >> There was a previous attempt at defining a binding for this, but Rob's NAK
> >> mentioned that a solution should cover both cases:
> >>
> >>  https://urldefense.com/v3/__https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzHFDBt_$  [lore[.]kernel[.]org]
> >>
> >> Having implemented nearly the same binding as what you describe, I obviously like your
> >> patch. Only thing I think that should be changed is the naming. A domain doesn't
> >> really describe this gated-by-fuses scenario I have. Calling it feature-gates
> >> instead OTOH makes sense for both your and my use case. Same goes for the documentation
> >> that could be worded more generically. I am open to other suggestions of course. :-)
> >>
> >> Also a general gpio-controller like property would be nice. It would allow drivers
> >> to easily check whether they are supposed to register a domain/feature controller.
> >> For devices like yours where a dedicated device node represents the domain controller,
> >> it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
> >> that, but I think a dedicated property may be better.
> >>
> >> Let me know what you think and thanks for working on this!
> >>
> >> Cheers,
> >> Ahmad
> >>
> > 
> > Hello Ahmad,
> > 
> > I'm very happy that you are interested in my proposal. It will be great
> > if we produce common binding to suite both our requirements.
> > I agree that binding should be renamed, but I don't think feature-gates
> > name would fit my case.
> > IIUC both our cases requires different devices across the system to
> > provide some information to the controller device. This information
> > could be used to identify the devices later or to make some
> > controller-specific configuration. In this case I would prefer name
> > "device-feature" or "bus-domain", suggested by Linus Walleij.
> > Also I like your idea to add dedicated property. This will make bindings
> > more clear.
> > Summarizing all above, I would suggest the following names:
> > 
> >  feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
> >      device-feature-controller;
> >      device-feature-cells = <1>;
> >  };
> > 
> >  &vpu_g1 {
> >      device-features = <&feat IMX8MP_VPU>;
> >  };
> > 
> > What do you think about this?
> 
> Sorry for the late answer. Full plate before vacation :)
> 
> A device- prefix for device properties is kind of redundant IMO.
> And [device-]features is somewhat ambiguous (it's not
> a list of features of the device, but a list of features that
> control the device). I see that gates might sounds a bit odd, how about
> feature-domains, feature-domain-controller, #feature-domain-cells?
> 
> Cheers,
> Ahmad
> 

Hello Ahmad,

feature-domains works for me as well. I will prepare patches if nobody
have any additional comments.

--
Oleksii

> > 
> > Best regards,
> > Oleksii.
> > 
> >>
> >>>
> >>> I think we can cooperate with the bus controller framework developers
> >>> and produce the common binding, which will fit the requirements of both
> >>> features
> >>>
> >>> Also, I think that binding can also be used for STM32 ETZPC bus
> >>> controller feature, proposed in the following thread: [2].
> >>>
> >>> Looking forward for your thoughts and ideas.
> >>>
> >>> [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH59KKjhc$  [developer[.]arm[.]com]
> >>> [1] https://urldefense.com/v3/__https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHy1kyyWZ$  [lore[.]kernel[.]org]
> >>> [2] https://urldefense.com/v3/__https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzVdVT4B$  [lore[.]kernel[.]org]
> >>>
> >>> ---
> >>> Changes v1 -> V2:
> >>>    - update parameter name, made it xen-specific
> >>>    - add xen vendor bindings
> >>>
> >>> Changes V2 -> V3:
> >>>    - update parameter name, make it generic
> >>>    - update parameter format, add link to controller
> >>>    - do not include xen vendor bindings as already upstreamed
> >>>
> >>> Changes V3 -> V4:
> >>>    - introduce domain controller provider/consumer device tree bindings
> >>>    - making scmi node to act as domain controller provider when the
> >>>      device permissions should be configured
> >>> ---
> >>>
> >>> Oleksii Moisieiev (2):
> >>>   dt-bindings: Document common device controller bindings
> >>>   dt-bindings: Update scmi node description
> >>>
> >>>  .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
> >>>  .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
> >>>  2 files changed, 105 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml
> >>>
> >>
> >>
> >> -- 
> >> Pengutronix e.K.                           |                             |
> >> Steuerwalder Str. 21                       | https://urldefense.com/v3/__http://www.pengutronix.de/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH_HqFmwM$  [pengutronix[.]de]  |
> >> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> >> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | https://urldefense.com/v3/__http://www.pengutronix.de/__;!!GF_29dbcQIUBPA!3ZZDuNOsR-mCQt8F9mbsVQvjDi0X_yfmxS65xA-VBjaknyBBRUGdS2y5z6lnRcdi0AfVhp0n_2LXh1V4GabWEUYzqKJ3$  [pengutronix[.]de]  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Peng Fan]

On 8/18/2022 5:05 PM, Oleksii Moisieiev wrote:
> On Mon, Aug 15, 2022 at 06:37:23PM +0200, Ahmad Fatoum wrote:
>> Hello Oleksii,
>>
>> On 07.07.22 12:25, Oleksii Moisieiev wrote:
>>> Introducing the domain controller provider/consumenr bindngs which allow to
>>> divided system on chip into multiple domains that can be used to select
>>> by who hardware blocks could be accessed.
>>> A domain could be a cluster of CPUs, a group of hardware blocks or the
>>> set of devices, passed-through to the Guest in the virtualized systems.
>>>
>>> Device controllers are typically used to set the permissions of the hardware
>>> block. The contents of the domain configuration properties are defined by the
>>> binding for the individual domain controller device.
>>>
>>> The device controller conception in the virtualized systems is to set
>>> the device configuration for SCMI (System Control and Management
>>> Interface) which controls clocks/power-domains/resets etc from the
>>> Firmware. This configuratio sets the device_id to set the device permissions
>>> for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
>>> There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
>>> determine device_id is not covered by the specification.
>>> Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
>>> Given parameter should set the device_id, needed to set device
>>> permissions in the Firmware.
>>> This property is used by trusted Agent (which is hypervisor in our case)
>>> to set permissions for the devices, passed-through to the non-trusted
>>> Agents. Trusted Agent will use device-perms to set the Device
>>> permissions for the Firmware (See Section 4.2.2.10 [0] for details).
>>> Agents concept is described in Section 4.2.1 [0].
>>>
>>> Domains in Device-tree node example:
>>> usb@e6590000
>>> {
>>>      domain-0 = <&scmi 19>; //Set domain id 19 to usb node
>>>      clocks = <&scmi_clock 3>, <&scmi_clock 2>;
>>>      resets = <&scmi_reset 10>, <&scmi_reset 9>;
>>>      power-domains = <&scmi_power 0>;
>>> };
>>>
>>> &scmi {
>>>      #domain-cells = <1>;
>>> }
>>>
>>> All mentioned bindings are going to be processed by XEN SCMI mediator
>>> feature, which is responsible to redirect SCMI calls from guests to the
>>> firmware, and not going be passed to the guests.
>>>
>>> Domain-controller provider/consumenr concept was taken from the bus
>>> controller framework patch series, provided in the following thread:
>>> [1].
>>
>> I also was inspired by Benjamin's series to draft up a binding, but for a slightly
>> different problem: Some SoCs like the i.MX8MP have a great deal of variation
>> in which IPs are actually available. After factory testing, fuses are burnt
>> to describe which IPs are available and as the upstream DT only describes
>> the full featured SoCs, either board DT or bootloader is expected to turn
>> off the device that are unavailable.
>>
>> What I came up with as a binding for the bootloader to guide its fixup
>> looks very similar to what you have:
>>
>> feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
>>      feature-controller;
>>      feature-cells = <1>;
>> };
>>
>> &vpu_g1 {
>>      features-gates = <&feat IMX8MP_VPU>;
>> };
>>
>> The OCOTP driver would see that it has a feature-controller property and register
>> a callback with a feature controller framework that checks whether a device
>> is available. barebox, that I implemented this binding for, would walk
>> the kernel device tree on boot looking for the feature-gates property and then
>> disable/delete nodes as indicated without having to write any SoC specific code
>> and especially without hardcoding node names and hierarchies, which is quite brittle.
>>
>> There was a previous attempt at defining a binding for this, but Rob's NAK
>> mentioned that a solution should cover both cases:
>>
>>   https://urldefense.com/v3/__https://lore.kernel.org/all/20220324042024.26813-1-peng.fan@oss.nxp.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzHFDBt_$  [lore[.]kernel[.]org]
>>
>> Having implemented nearly the same binding as what you describe, I obviously like your
>> patch. Only thing I think that should be changed is the naming. A domain doesn't
>> really describe this gated-by-fuses scenario I have. Calling it feature-gates
>> instead OTOH makes sense for both your and my use case. Same goes for the documentation
>> that could be worded more generically. I am open to other suggestions of course. :-)
>>
>> Also a general gpio-controller like property would be nice. It would allow drivers
>> to easily check whether they are supposed to register a domain/feature controller.
>> For devices like yours where a dedicated device node represents the domain controller,
>> it's redundant, but for a fuse bank, it's useful. #feature-cells could be used for
>> that, but I think a dedicated property may be better.
>>
>> Let me know what you think and thanks for working on this!
>>
>> Cheers,
>> Ahmad
>>
> 
> Hello Ahmad,
> 
> I'm very happy that you are interested in my proposal. It will be great
> if we produce common binding to suite both our requirements.
> I agree that binding should be renamed, but I don't think feature-gates
> name would fit my case.
> IIUC both our cases requires different devices across the system to
> provide some information to the controller device. This information
> could be used to identify the devices later or to make some
> controller-specific configuration. In this case I would prefer name
> "device-feature" or "bus-domain", suggested by Linus Walleij.
> Also I like your idea to add dedicated property. This will make bindings
> more clear.
> Summarizing all above, I would suggest the following names:
> 
>   feat: &ocotp { /* This is the efuse (On-Chip OTP) device */
>       device-feature-controller;
>       device-feature-cells = <1>;
>   };
> 
>   &vpu_g1 {
>       device-features = <&feat IMX8MP_VPU>;
>   };
> 
> What do you think about this?



For i.MX8MP, Uwe suggested:
	/ {
		fuse-info {
			compatible = "otp-fuse-info";

			flexcan {
				devices = <&flexcan1>, <&flexcan2>;
				nvmem-cells = <&flexcan_disabled>;
				nvmem-cell-names = "disabled";
			};

			m7 {
				....
			};
		};
	};
https://lore.kernel.org/all/20220324111104.cd7clpkzzedtcrja@pengutronix.de/

Regards,
Peng.

> 
> Best regards,
> Oleksii.
> 
>>
>>>
>>> I think we can cooperate with the bus controller framework developers
>>> and produce the common binding, which will fit the requirements of both
>>> features
>>>
>>> Also, I think that binding can also be used for STM32 ETZPC bus
>>> controller feature, proposed in the following thread: [2].
>>>
>>> Looking forward for your thoughts and ideas.
>>>
>>> [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH59KKjhc$  [developer[.]arm[.]com]
>>> [1] https://urldefense.com/v3/__https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHy1kyyWZ$  [lore[.]kernel[.]org]
>>> [2] https://urldefense.com/v3/__https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxHzVdVT4B$  [lore[.]kernel[.]org]
>>>
>>> ---
>>> Changes v1 -> V2:
>>>     - update parameter name, made it xen-specific
>>>     - add xen vendor bindings
>>>
>>> Changes V2 -> V3:
>>>     - update parameter name, make it generic
>>>     - update parameter format, add link to controller
>>>     - do not include xen vendor bindings as already upstreamed
>>>
>>> Changes V3 -> V4:
>>>     - introduce domain controller provider/consumer device tree bindings
>>>     - making scmi node to act as domain controller provider when the
>>>       device permissions should be configured
>>> ---
>>>
>>> Oleksii Moisieiev (2):
>>>    dt-bindings: Document common device controller bindings
>>>    dt-bindings: Update scmi node description
>>>
>>>   .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
>>>   .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
>>>   2 files changed, 105 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml
>>>
>>
>>
>> -- 
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       | https://urldefense.com/v3/__http://www.pengutronix.de/__;!!GF_29dbcQIUBPA!2j_vN6Jc1k2XI3EegAC2yzTLgJ1Rw1DhDrjGF03a5tDtOGpm_qp9B0zHJeAJzw-fWOeJp5HtnzYmOJZ0XPJxH_HqFmwM$  [pengutronix[.]de]  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Peng Fan]

Sorry for reply on V4, I not found V6 in my inbox.

Just wonder what is the status of V6
https://lore.kernel.org/lkml/0c0a82bb-18ae-d057-562b-21201bfe4fca@epam.com/

Thanks,
Peng

On 7/7/2022 6:25 PM, Oleksii Moisieiev wrote:
> Introducing the domain controller provider/consumenr bindngs which allow to
> divided system on chip into multiple domains that can be used to select
> by who hardware blocks could be accessed.
> A domain could be a cluster of CPUs, a group of hardware blocks or the
> set of devices, passed-through to the Guest in the virtualized systems.
> 
> Device controllers are typically used to set the permissions of the hardware
> block. The contents of the domain configuration properties are defined by the
> binding for the individual domain controller device.
> 
> The device controller conception in the virtualized systems is to set
> the device configuration for SCMI (System Control and Management
> Interface) which controls clocks/power-domains/resets etc from the
> Firmware. This configuratio sets the device_id to set the device permissions
> for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]).
> There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
> determine device_id is not covered by the specification.
> Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
> Given parameter should set the device_id, needed to set device
> permissions in the Firmware.
> This property is used by trusted Agent (which is hypervisor in our case)
> to set permissions for the devices, passed-through to the non-trusted
> Agents. Trusted Agent will use device-perms to set the Device
> permissions for the Firmware (See Section 4.2.2.10 [0] for details).
> Agents concept is described in Section 4.2.1 [0].
> 
> Domains in Device-tree node example:
> usb@e6590000
> {
>      domain-0 = <&scmi 19>; //Set domain id 19 to usb node
>      clocks = <&scmi_clock 3>, <&scmi_clock 2>;
>      resets = <&scmi_reset 10>, <&scmi_reset 9>;
>      power-domains = <&scmi_power 0>;
> };
> 
> &scmi {
>      #domain-cells = <1>;
> }
> 
> All mentioned bindings are going to be processed by XEN SCMI mediator
> feature, which is responsible to redirect SCMI calls from guests to the
> firmware, and not going be passed to the guests.
> 
> Domain-controller provider/consumenr concept was taken from the bus
> controller framework patch series, provided in the following thread:
> [1].
> 
> I think we can cooperate with the bus controller framework developers
> and produce the common binding, which will fit the requirements of both
> features
> 
> Also, I think that binding can also be used for STM32 ETZPC bus
> controller feature, proposed in the following thread: [2].
> 
> Looking forward for your thoughts and ideas.
> 
> [0] https://developer.arm.com/documentation/den0056/latest
> [1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/
> [2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/
> 
> ---
> Changes v1 -> V2:
>     - update parameter name, made it xen-specific
>     - add xen vendor bindings
> 
> Changes V2 -> V3:
>     - update parameter name, make it generic
>     - update parameter format, add link to controller
>     - do not include xen vendor bindings as already upstreamed
> 
> Changes V3 -> V4:
>     - introduce domain controller provider/consumer device tree bindings
>     - making scmi node to act as domain controller provider when the
>       device permissions should be configured
> ---
> 
> Oleksii Moisieiev (2):
>    dt-bindings: Document common device controller bindings
>    dt-bindings: Update scmi node description
> 
>   .../bindings/domains/domain-controller.yaml   | 80 +++++++++++++++++++
>   .../bindings/firmware/arm,scmi.yaml           | 25 ++++++
>   2 files changed, 105 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/domains/domain-controller.yaml
> 

[PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Oleksii Moisieiev]

Introducing the feature domain controller provider/consumenr bindngs which
allow to divided system on chip into multiple feature domains that
can be used to select by who hardware blocks could be accessed.
A feature-domain could be a cluster of CPUs, a group of hardware blocks or
the set of devices, passed-through to the Guest in the virtualized systems.

Feature domains controllers are typically used to set the permissions of
the hardware block. The contents of the feature domain configuration
properties are defined by the binding for the individual
feature domain controller device.

The feature device controller conception in the virtualized systems is to
set the device configuration for SCMI (System Control and Management
Interface) which controls clocks/power-domains/resets etc from the
Firmware. This configuratio sets the device_id to set the device
permissions for the Firmware using BASE_SET_DEVICE_PERMISSIONS
message (see 4.2.2.10 of [0]).
There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
determine device_id is not covered by the specification.
Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
Given parameter should set the device_id, needed to set device
permissions in the Firmware.
This property is used by trusted Agent (which is hypervisor in our case)
to set permissions for the devices, passed-through to the non-trusted
Agents. Trusted Agent will use device-perms to set the Device
permissions for the Firmware (See Section 4.2.2.10 [0] for details).
Agents concept is described in Section 4.2.1 [0].

Feature-Domains in Device-tree node example:
usb@e6590000
{
    feature-domains = <&scmi 19>; //Set domain id 19 to usb node
    feature-domain-names = "scmi";
    clocks = <&scmi_clock 3>, <&scmi_clock 2>;
    resets = <&scmi_reset 10>, <&scmi_reset 9>;
    power-domains = <&scmi_power 0>;
};

&scmi {
    feature-domain-controller;
    #feature-domain-cells = <1>;
}

All mentioned bindings are going to be processed by XEN SCMI mediator
feature, which is responsible to redirect SCMI calls from guests to the
firmware, and not going be passed to the guests.

Feature-domain-controller provider/consumenr concept was taken from the bus
controller framework patch series, provided in the following thread:
[1].

I think we can cooperate with the bus controller framework developers
and produce the common binding, which will fit the requirements of both
features

Also, I think that binding can also be used for STM32 ETZPC bus
controller feature, proposed in the following thread: [2].

Looking forward for your thoughts and ideas.

[0] https://developer.arm.com/documentation/den0056/latest
[1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/
[2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/

---
Changes v1 -> V2:
   - update parameter name, made it xen-specific
   - add xen vendor bindings

Changes V2 -> V3:
   - update parameter name, make it generic
   - update parameter format, add link to controller
   - do not include xen vendor bindings as already upstreamed

Changes V3 -> V4:
   - introduce domain controller provider/consumer device tree bindings
   - making scmi node to act as domain controller provider when the
     device permissions should be configured

Changes V4 -> V5:
   - rename domain-controller to feature-domain-controller
   - feature-domains format fixes

Changes V5 -> V6:
   - formatting fixes

Oleksii Moisieiev (2):
  dt-bindings: Update scmi node description
  dt-bindings: Document common device controller bindings

 .../feature-domain-controller.yaml            | 84 +++++++++++++++++++
 .../bindings/firmware/arm,scmi.yaml           | 28 +++++++
 MAINTAINERS                                   |  6 ++
 3 files changed, 118 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml

-- 
2.25.1

[PATCH v4 0/2] dt-bindings: Intorduce domain-controller

[Oleksii Moisieiev]

Introducing the feature domain controller provider/consumenr bindngs which
allow to divided system on chip into multiple feature domains that
can be used to select by who hardware blocks could be accessed.
A feature-domain could be a cluster of CPUs, a group of hardware blocks or
the set of devices, passed-through to the Guest in the virtualized systems.

Feature domains controllers are typically used to set the permissions of
the hardware block. The contents of the feature domain configuration
properties are defined by the binding for the individual
feature domain controller device.

The feature device controller conception in the virtualized systems is to
set the device configuration for SCMI (System Control and Management
Interface) which controls clocks/power-domains/resets etc from the
Firmware. This configuratio sets the device_id to set the device
permissions for the Firmware using BASE_SET_DEVICE_PERMISSIONS
message (see 4.2.2.10 of [0]).
There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to
determine device_id is not covered by the specification.
Device permissions management described in DEN 0056, Section 4.2.2.10 [0].
Given parameter should set the device_id, needed to set device
permissions in the Firmware.
This property is used by trusted Agent (which is hypervisor in our case)
to set permissions for the devices, passed-through to the non-trusted
Agents. Trusted Agent will use device-perms to set the Device
permissions for the Firmware (See Section 4.2.2.10 [0] for details).
Agents concept is described in Section 4.2.1 [0].

Feature-Domains in Device-tree node example:
usb@e6590000
{
    feature-domains = <&scmi 19>; //Set domain id 19 to usb node
    feature-domain-names = "scmi";
    clocks = <&scmi_clock 3>, <&scmi_clock 2>;
    resets = <&scmi_reset 10>, <&scmi_reset 9>;
    power-domains = <&scmi_power 0>;
};

&scmi {
    feature-domain-controller;
    #feature-domain-cells = <1>;
}

All mentioned bindings are going to be processed by XEN SCMI mediator
feature, which is responsible to redirect SCMI calls from guests to the
firmware, and not going be passed to the guests.

Feature-domain-controller provider/consumenr concept was taken from the bus
controller framework patch series, provided in the following thread:
[1].

I think we can cooperate with the bus controller framework developers
and produce the common binding, which will fit the requirements of both
features

Also, I think that binding can also be used for STM32 ETZPC bus
controller feature, proposed in the following thread: [2].

Looking forward for your thoughts and ideas.

[0] https://developer.arm.com/documentation/den0056/latest
[1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/
[2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/

---
Changes v1 -> V2:
   - update parameter name, made it xen-specific
   - add xen vendor bindings

Changes V2 -> V3:
   - update parameter name, make it generic
   - update parameter format, add link to controller
   - do not include xen vendor bindings as already upstreamed

Changes V3 -> V4:
   - introduce domain controller provider/consumer device tree bindings
   - making scmi node to act as domain controller provider when the
     device permissions should be configured

Changes V4 -> V5:
   - rename domain-controller to feature-domain-controller
   - feature-domains format fixes

Changes V5 -> V6:
   - formatting fixes

Oleksii Moisieiev (2):
  dt-bindings: Update scmi node description
  dt-bindings: Document common device controller bindings

 .../feature-domain-controller.yaml            | 84 +++++++++++++++++++
 .../bindings/firmware/arm,scmi.yaml           | 28 +++++++
 MAINTAINERS                                   |  6 ++
 3 files changed, 118 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml

-- 
2.25.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel