Document STM32 System Bus. This bus is intended to control firewall
access for the peripherals connected to it.
For every peripheral, the bus checks the firewall registers to see
if the peripheral is configured as non-secure. If the peripheral
is configured as secure, the node is marked populated, so the
device won't be probed.
This is useful as a firewall configuration sanity check and avoid
platform crashes in case peripherals are incorrectly configured.
The STM32 System Bus implements the feature-domain-controller
bindings. It is used by peripherals to reference a domain
controller, in this case the firewall feature domain.
The bus uses the ID referenced by the feature-domains property to
know where to look in the firewall to get the security configuration
for the peripheral. This allows a device tree description rather
than a hardcoded peripheral table in the bus driver.
On STM32MP13/15 platforms, the firewall bus is represented by the
ETZPC node, which is responsible for the securing / MCU isolating
the capable peripherals.
STM32MP13/15 device trees are updated in this series to implement
the bus. All peripherals that are securable or MCU isolation capable
by the ETZPC are connected to the bus.
Gatien Chevallier (6):
dt-bindings: bus: add STM32 System Bus
dt-bindings: bus: add STM32MP15 ETZPC firewall bus bindings
dt-bindings: bus: add STM32MP13 ETZPC firewall bus bindings
bus: stm32_sys_bus: add support for STM32MP15 and STM32MP13 system bus
ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
Oleksii Moisieiev (1):
dt-bindings: Document common device controller bindings
.../devicetree/bindings/bus/st,sys-bus.yaml | 88 +
.../feature-domain-controller.yaml | 84 +
MAINTAINERS | 6 +
arch/arm/boot/dts/stm32mp131.dtsi | 242 +-
arch/arm/boot/dts/stm32mp151.dtsi | 2737 +++++++++--------
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 1 +
drivers/bus/stm32_sys_bus.c | 180 ++
include/dt-bindings/bus/stm32mp13_sys_bus.h | 60 +
include/dt-bindings/bus/stm32mp15_sys_bus.h | 98 +
10 files changed, 2062 insertions(+), 1443 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/st,sys-bus.yaml
create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml
create mode 100644 drivers/bus/stm32_sys_bus.c
create mode 100644 include/dt-bindings/bus/stm32mp13_sys_bus.h
create mode 100644 include/dt-bindings/bus/stm32mp15_sys_bus.h
--
2.25.1
From: Oleksii Moisieiev <[email protected]>
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 <[email protected]>
---
.../feature-domain-controller.yaml | 84 +++++++++++++++++++
1 file changed, 84 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 <[email protected]>
+
+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";
+ };
--
2.25.1
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
On 21/12/2022 18:30, Gatien Chevallier wrote:
> From: Oleksii Moisieiev <[email protected]>
You same From as SoB.
>
> 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 <[email protected]>
Missing SoB.
Missing changelog. This is not v1 but v7 or something.
> ---
> .../feature-domain-controller.yaml | 84 +++++++++++++++++++
> 1 file changed, 84 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
Drop "bindings".
Anyway you duplicate work here:
https://lore.kernel.org/all/c869d2751125181a55bc8a88c96e3a892b42f37a.1668070216.git.oleksii_moisieiev@epam.com/
and maybe you duplicate comments.
I don't think there is point to review things twice, so NAK.
Best regards,
Krzysztof
Hello Krzysztof,
On 12/22/22 11:22, Krzysztof Kozlowski wrote:
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
>
>
> On 21/12/2022 18:30, Gatien Chevallier wrote:
>> From: Oleksii Moisieiev <[email protected]>
>
> You same From as SoB.
>
>>
>> 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 <[email protected]>
>
> Missing SoB.
>
> Missing changelog. This is not v1 but v7 or something >
>
>
>> ---
>> .../feature-domain-controller.yaml | 84 +++++++++++++++++++
>> 1 file changed, 84 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
>
> Drop "bindings".
>
> Anyway you duplicate work here:
> https://lore.kernel.org/all/c869d2751125181a55bc8a88c96e3a892b42f37a.1668070216.git.oleksii_moisieiev@epam.com/
> and maybe you duplicate comments.
>
> I don't think there is point to review things twice, so NAK.
This is a result of me not knowing how to handle this particular case.
It is a patch that I need to have in my patch set in order to pass Rob's
bindings check. Otherwise, feature domains bindings defined here will
not be known in the STM32 System Bus binding file, where they are used.
I wanted to illustrate the use of Oleksii's binding with a practical
use-case that we want to implement.
What would be the correct way of managing this dependency?
-Specify something like "On top of ...." in the cover letter/patch and
reference the other thread?
-Use a "Depends-On" tag on the YAML binding commit?
-Something else?
Best regards,
Gatien
>
>
> Best regards,
> Krzysztof
>
On 22/12/2022 14:01, Gatien CHEVALLIER wrote:
>
>>
>> Anyway you duplicate work here:
>> https://lore.kernel.org/all/c869d2751125181a55bc8a88c96e3a892b42f37a.1668070216.git.oleksii_moisieiev@epam.com/
>> and maybe you duplicate comments.
>>
>> I don't think there is point to review things twice, so NAK.
> This is a result of me not knowing how to handle this particular case.
> It is a patch that I need to have in my patch set in order to pass Rob's
> bindings check. Otherwise, feature domains bindings defined here will
> not be known in the STM32 System Bus binding file, where they are used.
>
> I wanted to illustrate the use of Oleksii's binding with a practical
> use-case that we want to implement.
Mention patch dependency in the path changelog (---) and that's it. No
tests will be done. You are expected to run tests anyway on your side,
before sending.
>
> What would be the correct way of managing this dependency?
> -Specify something like "On top of ...." in the cover letter/patch and
> reference the other thread?
> -Use a "Depends-On" tag on the YAML binding commit?
> -Something else?
Best regards,
Krzysztof