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

[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

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

[Oleksii Moisieiev]

Add '#feature-domain-cells' property description to the scmi node.
This property makes scmi node as feature-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
Firmware 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

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

Changes V5 -> V6:
   - formatting fixes
---
 .../bindings/firmware/arm,scmi.yaml           | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 1c0388da6721..bb5aa49e88fd 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -89,6 +89,16 @@ properties:
       atomic mode of operation, even if requested.
     default: 0
 
+  '#feature-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
+
+  feature-domain-controller: true
+
   arm,smc-id:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
@@ -429,4 +439,22 @@ 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>;
+            feature-domain-controller;
+            #feature-domain-cells = <1>;
+        };
+    };
+
+    foo@0 {
+      reg = <0x0 0x10>;
+      feature-domains = <&scmi_link 1>;
+    };
 ...
-- 
2.25.1

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

[Oleksii Moisieiev]

Add '#feature-domain-cells' property description to the scmi node.
This property makes scmi node as feature-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
Firmware 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

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

Changes V5 -> V6:
   - formatting fixes
---
 .../bindings/firmware/arm,scmi.yaml           | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 1c0388da6721..bb5aa49e88fd 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -89,6 +89,16 @@ properties:
       atomic mode of operation, even if requested.
     default: 0
 
+  '#feature-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
+
+  feature-domain-controller: true
+
   arm,smc-id:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
@@ -429,4 +439,22 @@ 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>;
+            feature-domain-controller;
+            #feature-domain-cells = <1>;
+        };
+    };
+
+    foo@0 {
+      reg = <0x0 0x10>;
+      feature-domains = <&scmi_link 1>;
+    };
 ...
-- 
2.25.1

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

[PATCH v6 2/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>
---
 .../feature-domain-controller.yaml            | 84 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++
 2 files changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml

diff --git a/Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml b/Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml
new file mode 100644
index 000000000000..90a7c38c833c
--- /dev/null
+++ b/Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/feature-controllers/feature-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 Feature Domains Controller bindings properties
+
+  Domain controllers 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 (or coprocessors), a range of
+  addresses or a group of hardware blocks.
+
+  This device tree bindings can be used to bind feature domain consumer devices
+  with their feature domains provided by feature-domains controllers.
+  Feature omain 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
+  '#feature-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 feature-domains configuration properties are
+  defined by the binding for the individual feature-domains controller device.
+
+  Each node can be a consumer for the several providers. The first
+  configuration of 'feature-domains' or the one named 'default' is applied
+  before probing the device itself.
+
+# always select the core schema
+select: true
+
+properties:
+  '#feature-domain-cells':
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Number of cells in a feature-domains controller specifier;
+      Can be any value as specified by device tree binding documentation
+      of a particular provider.
+
+  feature-domain-controller:
+    description:
+      Indicates that the node is feature-domain-controller provider.
+
+  feature-domain-names:
+    $ref: '/schemas/types.yaml#/definitions/string-array'
+    description:
+      A list of feature-domains names, sorted in the same order as
+      feature-domains entries. Consumer drivers will use feature-domain-names
+      to match with existing feature-domains entries.
+
+  feature-domains:
+    $ref: "/schemas/types.yaml#/definitions/phandle-array"
+    description:
+      A list of feature-domains controller specifiers, as defined by the
+      bindings of the feature-domain-controller provider.
+
+additionalProperties: true
+
+examples:
+  - |
+    ctrl0: ctrl@100 {
+        feature-domain-controller;
+        reg = <0x100 0x10>;
+        #feature-domain-cells = <2>;
+    };
+
+    ctrl1: ctrl@110 {
+        feature-domain-controller;
+        reg = <0x110 0x10>;
+        #feature-domain-cells = <3>;
+    };
+
+    foo@0 {
+        reg = <0x0 0x1>;
+        feature-domains = <&ctrl0 1 2>, <&ctrl1 3 4 5>;
+        feature-domain-names = "default", "unbind";
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 046ff06ff97f..2d1a5023e61c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7920,6 +7920,12 @@ F:	include/scsi/libfc.h
 F:	include/scsi/libfcoe.h
 F:	include/uapi/scsi/fc/
 
+FEATURE CONTROLLERS
+M:	Oleksii Moiseev <oleksii_moisieiev@epam.com>
+L:	devicetree@vger.kernel.org
+S:	Maintained
+F:	Documentation/deviceree/bindings/feature-controllers/feature-domain-controller.yaml
+
 FILE LOCKING (flock() and fcntl()/lockf())
 M:	Jeff Layton <jlayton@kernel.org>
 M:	Chuck Lever <chuck.lever@oracle.com>
-- 
2.25.1

[PATCH v6 2/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>
---
 .../feature-domain-controller.yaml            | 84 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++
 2 files changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml

diff --git a/Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml b/Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml
new file mode 100644
index 000000000000..90a7c38c833c
--- /dev/null
+++ b/Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/feature-controllers/feature-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 Feature Domains Controller bindings properties
+
+  Domain controllers 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 (or coprocessors), a range of
+  addresses or a group of hardware blocks.
+
+  This device tree bindings can be used to bind feature domain consumer devices
+  with their feature domains provided by feature-domains controllers.
+  Feature omain 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
+  '#feature-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 feature-domains configuration properties are
+  defined by the binding for the individual feature-domains controller device.
+
+  Each node can be a consumer for the several providers. The first
+  configuration of 'feature-domains' or the one named 'default' is applied
+  before probing the device itself.
+
+# always select the core schema
+select: true
+
+properties:
+  '#feature-domain-cells':
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Number of cells in a feature-domains controller specifier;
+      Can be any value as specified by device tree binding documentation
+      of a particular provider.
+
+  feature-domain-controller:
+    description:
+      Indicates that the node is feature-domain-controller provider.
+
+  feature-domain-names:
+    $ref: '/schemas/types.yaml#/definitions/string-array'
+    description:
+      A list of feature-domains names, sorted in the same order as
+      feature-domains entries. Consumer drivers will use feature-domain-names
+      to match with existing feature-domains entries.
+
+  feature-domains:
+    $ref: "/schemas/types.yaml#/definitions/phandle-array"
+    description:
+      A list of feature-domains controller specifiers, as defined by the
+      bindings of the feature-domain-controller provider.
+
+additionalProperties: true
+
+examples:
+  - |
+    ctrl0: ctrl@100 {
+        feature-domain-controller;
+        reg = <0x100 0x10>;
+        #feature-domain-cells = <2>;
+    };
+
+    ctrl1: ctrl@110 {
+        feature-domain-controller;
+        reg = <0x110 0x10>;
+        #feature-domain-cells = <3>;
+    };
+
+    foo@0 {
+        reg = <0x0 0x1>;
+        feature-domains = <&ctrl0 1 2>, <&ctrl1 3 4 5>;
+        feature-domain-names = "default", "unbind";
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 046ff06ff97f..2d1a5023e61c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7920,6 +7920,12 @@ F:	include/scsi/libfc.h
 F:	include/scsi/libfcoe.h
 F:	include/uapi/scsi/fc/
 
+FEATURE CONTROLLERS
+M:	Oleksii Moiseev <oleksii_moisieiev@epam.com>
+L:	devicetree@vger.kernel.org
+S:	Maintained
+F:	Documentation/deviceree/bindings/feature-controllers/feature-domain-controller.yaml
+
 FILE LOCKING (flock() and fcntl()/lockf())
 M:	Jeff Layton <jlayton@kernel.org>
 M:	Chuck Lever <chuck.lever@oracle.com>
-- 
2.25.1

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

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

[Oleksii Moisieiev]

Hello,

There were typo in the cover letter subject. Patch series are related to 
v6, not v4. I've fixed Subject in this letter.
I'm sorry for the inconvenience.

Thanks,
Oleksii.

On 10.11.22 10:57, Oleksii Moisieiev wrote:
> 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
> 

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

[Oleksii Moisieiev]

Hello,

There were typo in the cover letter subject. Patch series are related to 
v6, not v4. I've fixed Subject in this letter.
I'm sorry for the inconvenience.

Thanks,
Oleksii.

On 10.11.22 10:57, Oleksii Moisieiev wrote:
> 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
> 
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel