[RFC,v2,0/7] Introduce STM32 system bus

Message

Gatien CHEVALLIER Dec. 22, 2022, 10:04 a.m. UTC

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.

Changes in V2:
	- Corrected YAMLS errors highlighted by Rob's robot
	- Re-ordered Signed-off-by tags in two patches

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

Comments

Greg KH Dec. 22, 2022, 4:39 p.m. UTC | #1

On Thu, Dec 22, 2022 at 11:04:57AM +0100, Gatien Chevallier wrote:
> Document STM32 System Bus. This bus is intended to control firewall
> access for the peripherals connected to it.

Why is this an "RFC"?  That usually means "I have more work to do on it,
but I'll send it out now anyway".  What work is left?

And for most code, I know I don't review "RFC" changes as there are too
many "real" patches being submitted where people think their code is
ready to be merged.  Other reviewers might think otherwise, but be aware
of this...

thanks,

greg k-h

Gatien CHEVALLIER Jan. 3, 2023, 9:45 a.m. UTC | #2

Hello Greg,

I've put the "RFC" tag on the the patch set as it is based on bindings 
that are currently under review. It has been submitted with the idea to 
support the bindings proposed by Oleksii. Apart from this and the 
comments made by Krzysztof, there is indeed no more "work" planned on 
this change.

Should the "RFC" tag be omitted for the next version?

Best regards,
Gatien

On 12/22/22 17:39, Greg KH wrote:
> On Thu, Dec 22, 2022 at 11:04:57AM +0100, Gatien Chevallier wrote:
>> Document STM32 System Bus. This bus is intended to control firewall
>> access for the peripherals connected to it.
> 
> Why is this an "RFC"?  That usually means "I have more work to do on it,
> but I'll send it out now anyway".  What work is left?
> 
> And for most code, I know I don't review "RFC" changes as there are too
> many "real" patches being submitted where people think their code is
> ready to be merged.  Other reviewers might think otherwise, but be aware
> of this...
> 
> thanks,
> 
> greg k-h

Greg KH Jan. 4, 2023, 6:10 a.m. UTC | #3

On Tue, Jan 03, 2023 at 10:45:15AM +0100, Gatien CHEVALLIER wrote:
> Hello Greg,
> 
> I've put the "RFC" tag on the the patch set as it is based on bindings that
> are currently under review. It has been submitted with the idea to support
> the bindings proposed by Oleksii. Apart from this and the comments made by
> Krzysztof, there is indeed no more "work" planned on this change.
> 
> Should the "RFC" tag be omitted for the next version?

If you feel it is ready to be merged, yes, then please remove it,
otherwise it's obviously not ready and will not be merged :)

thanks,

greg k-h