On 10/09/2025 10:42, Gatien CHEVALLIER wrote:
On 9/10/25 09:47, Clément Le Goffic wrote:
On 09/09/2025 14:25, Gatien CHEVALLIER wrote:
On 9/9/25 12:12, Clément Le Goffic wrote:
From: Clément Le Goffic <clement.legoffic@xxxxxxxxxxx>
Other driver than rifsc and etzpc can implement firewall ops, such as
rcc.
In order for them to have access to the ops and type of this framework,
we need to get the `stm32_firewall.h` file in the include/ folder.
Signed-off-by: Clément Le Goffic <clement.legoffic@xxxxxxxxxxx>
Signed-off-by: Clément Le Goffic <legoffic.clement@xxxxxxxxx>
---
drivers/bus/stm32_etzpc.c | 3 +--
drivers/bus/stm32_firewall.c | 3 +--
drivers/bus/stm32_rifsc.c | 3 +--
{drivers => include/linux}/bus/stm32_firewall.h | 0
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/stm32_etzpc.c b/drivers/bus/stm32_etzpc.c
index 7fc0f16960be..4918a14e507e 100644
--- a/drivers/bus/stm32_etzpc.c
+++ b/drivers/bus/stm32_etzpc.c
@@ -5,6 +5,7 @@
#include <linux/bitfield.h>
#include <linux/bits.h>
+#include <linux/bus/stm32_firewall.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/init.h>
@@ -16,8 +17,6 @@
#include <linux/platform_device.h>
#include <linux/types.h>
-#include "stm32_firewall.h"
-
/*
* ETZPC registers
*/
diff --git a/drivers/bus/stm32_firewall.c b/drivers/bus/
stm32_firewall.c
index 2fc9761dadec..ef4988054b44 100644
--- a/drivers/bus/stm32_firewall.c
+++ b/drivers/bus/stm32_firewall.c
@@ -5,6 +5,7 @@
#include <linux/bitfield.h>
#include <linux/bits.h>
+#include <linux/bus/stm32_firewall.h>
#include <linux/bus/stm32_firewall_device.h>
#include <linux/device.h>
#include <linux/err.h>
@@ -18,8 +19,6 @@
#include <linux/types.h>
#include <linux/slab.h>
-#include "stm32_firewall.h"
-
/* Corresponds to STM32_FIREWALL_MAX_EXTRA_ARGS + firewall ID */
#define STM32_FIREWALL_MAX_ARGS (STM32_FIREWALL_MAX_EXTRA_ARGS + 1)
diff --git a/drivers/bus/stm32_rifsc.c b/drivers/bus/stm32_rifsc.c
index 4cf1b60014b7..643ddd0a5f54 100644
--- a/drivers/bus/stm32_rifsc.c
+++ b/drivers/bus/stm32_rifsc.c
@@ -5,6 +5,7 @@
#include <linux/bitfield.h>
#include <linux/bits.h>
+#include <linux/bus/stm32_firewall.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/init.h>
@@ -16,8 +17,6 @@
#include <linux/platform_device.h>
#include <linux/types.h>
-#include "stm32_firewall.h"
-
/*
* RIFSC offset register
*/
diff --git a/drivers/bus/stm32_firewall.h b/include/linux/bus/
stm32_firewall.h
similarity index 100%
rename from drivers/bus/stm32_firewall.h
rename to include/linux/bus/stm32_firewall.h
Hi Gatien
As the firewall header is moved to a dedicated firewall directory,
I don't move it to a dedicated firewall directory just to the "bus"
directory where the "stm32_firewall_device.h" header file is already
located.
Yes, my bad, I mixed my words there.
maybe it would be coherent to create the same kind of directory
for the sources as non-buses drivers use it. I can test it on my
side if you're willing to make the change.
Do you mean create an include/linux/bus/firewall/ directory ?
Rather include/linux/firewall/(stm32/). and a drivers/firewall/(stm32/)
directory for the firewall files would be great. If that's not too much
of a burden.
I thinks that's a bit too much for this one.
As you're the firewall maintainer I would need to modify your entry in
the MAINTAINER file (and I just see that your entry is lacking the
header file path).
For now I think it is not urgent neither mandatory.
Maybe in a next patch series ?
Even in the driver bus directory there is no vendor policy so adding a
path like drivers/bus/{stm32/|firewall/}stm32_firewall.c is a bit
overlapping as with the filename we already know it is ST and its firewall.
Let me know what you think !
BR,
Clément
