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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 4 Apr 2023 14:02:14 +0800
From:   Peng Fan <peng.fan@....nxp.com>
To:     Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Cc:     "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "alexandre.torgue@...com" <alexandre.torgue@...com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "tomase@...inx.com" <tomase@...inx.com>,
        "benjamin.gaignard@...com" <benjamin.gaignard@...com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "fabio.estevam@....com" <fabio.estevam@....com>,
        "loic.pallardy@...com" <loic.pallardy@...com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Cristian Marussi <cristian.marussi@....com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller

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@...90000
> {
>      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
>