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

[Rob Herring <robh@kernel.org>]

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