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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220720213221.GA3987398-robh@kernel.org>
Date:   Wed, 20 Jul 2022 15:32:21 -0600
From:   Rob Herring <robh@...nel.org>
To:     Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>
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

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