[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200128153806.7780-1-benjamin.gaignard@st.com>
Date: Tue, 28 Jan 2020 16:37:59 +0100
From: Benjamin Gaignard <benjamin.gaignard@...com>
To: <broonie@...nel.org>, <robh@...nel.org>, <arnd@...db.de>,
<shawnguo@...nel.org>, <s.hauer@...gutronix.de>,
<fabio.estevam@....com>, <sudeep.holla@....com>, <lkml@...ux.net>
CC: <loic.pallardy@...com>, <gregkh@...uxfoundation.org>,
<linux-kernel@...r.kernel.org>, <linux-imx@....com>,
<kernel@...gutronix.de>, <linux-arm-kernel@...ts.infradead.org>,
<devicetree@...r.kernel.org>, <system-dt@...ts.openampproject.org>,
<stefano.stabellini@...inx.com>,
Benjamin Gaignard <benjamin.gaignard@...com>
Subject: [PATCH v2 0/7] Introduce bus firewall controller framework
Bus firewall framework aims to provide a kernel API to set the configuration
of the harware blocks in charge of busses access control.
Framework architecture is inspirated by pinctrl framework:
- a default configuration could be applied before bind the driver.
If a configuration could not be applied the driver is not bind
to avoid doing accesses on prohibited regions.
- configurations could be apllied dynamically by drivers.
- device node provides the bus firewall configurations.
An example of bus firewall controller is STM32 ETZPC hardware block
which got 3 possible configurations:
- trust: hardware blocks are only accessible by software running on trust
zone (i.e op-tee firmware).
- non-secure: hardware blocks are accessible by non-secure software (i.e.
linux kernel).
- coprocessor: hardware blocks are only accessible by the coprocessor.
Up to 94 hardware blocks of the soc could be managed by ETZPC.
At least two other hardware blocks can take benefits of this:
- ARM TZC-400: http://infocenter.arm.com/help/topic/com.arm.doc.100325_0001_02_en/arm_corelink_tzc400_trustzone_address_space_controller_trm_100325_0001_02_en.pdf
which is able to manage up to 8 regions in address space.
- IMX Ressource Domain Controller (RDC): supports four domains and up to eight regions
Version 2 has been rebased on top of v5.5
- Change framework name to "firewall" because the targeted hardware block
are acting like firewall on the busses.
- Mark Brown had reviewed the previous version but it was on kernel 5.1 and I change
the name framework so I have decided to remove it.
- Use yaml file to describe the bindings
Benjamin
Benjamin Gaignard (7):
dt-bindings: bus: Add firewall bindings
bus: Introduce firewall controller framework
base: Add calls to firewall controller
dt-bindings: bus: Add STM32 ETZPC firewall controller
bus: firewall: Add driver for STM32 ETZPC controller
ARM: dts: stm32: Add firewall node for stm32mp157 SoC
ARM: dts: stm32: enable firewall controller node on stm32mp157c-ed1
.../bindings/bus/firewall/firewall-consumer.yaml | 25 ++
.../bindings/bus/firewall/firewall-provider.yaml | 18 ++
.../bindings/bus/firewall/st,stm32-etzpc.yaml | 41 ++++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 2 +
arch/arm/boot/dts/stm32mp157c.dtsi | 7 +
drivers/base/dd.c | 9 +
drivers/bus/Kconfig | 2 +
drivers/bus/Makefile | 2 +
drivers/bus/firewall/Kconfig | 14 ++
drivers/bus/firewall/Makefile | 2 +
drivers/bus/firewall/firewall.c | 264 +++++++++++++++++++++
drivers/bus/firewall/stm32-etzpc.c | 140 +++++++++++
include/dt-bindings/bus/firewall/stm32-etzpc.h | 90 +++++++
include/linux/firewall.h | 70 ++++++
14 files changed, 686 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/firewall/firewall-consumer.yaml
create mode 100644 Documentation/devicetree/bindings/bus/firewall/firewall-provider.yaml
create mode 100644 Documentation/devicetree/bindings/bus/firewall/st,stm32-etzpc.yaml
create mode 100644 drivers/bus/firewall/Kconfig
create mode 100644 drivers/bus/firewall/Makefile
create mode 100644 drivers/bus/firewall/firewall.c
create mode 100644 drivers/bus/firewall/stm32-etzpc.c
create mode 100644 include/dt-bindings/bus/firewall/stm32-etzpc.h
create mode 100644 include/linux/firewall.h
--
2.15.0
Powered by blists - more mailing lists