Add device tree bindings for the Renesas Multifunctional Interface
(MFIS) as found on the Renesas R-Car X5H (r8a78000) SoC. MFIS includes
features like Mailbox/HW Spinlock/Product Register.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Checked with 'dt_bindings_check'. Family-compatible values are not
introduced here because MFIS is usually very different per SoC.
.../soc/renesas/renesas,r8a78000-mfis.yaml | 160 ++++++++++++++++++
.../mailbox/renesas,r8a78000-mfis.h | 27 +++
2 files changed, 187 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
create mode 100644 include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
new file mode 100644
index 000000000000..dbda28ac781c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas,r8a78000-mfis.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas MFIS (Multifunctional Interface) controller
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+description:
+ Renesas Multifunctional Interface (MFIS) provides functionality for
+ communication between different CPU cores. Those cores can be in various
+ domains like AP, RT, or SCP. Functionality includes features like
+ mailboxes, hardware spinlocks and such.
+
+properties:
+ compatible:
+ enum:
+ - renesas,r8a78000-mfis # R-Car X5H (AP<->AP, with PRR)
+ - renesas,r8a78000-mfis-scp # R-Car X5H (AP<->SCP, without PRR)
+
+ reg:
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: common
+ - const: mboxes
+
+ interrupts:
+ minItems: 32
+ maxItems: 128
+ description:
+ The interrupts raised by the remote doorbells.
+
+ interrupt-names:
+ minItems: 32
+ maxItems: 128
+ items:
+ pattern: "^ch[0-9]+[ie]$"
+ description:
+ An interrupt name is constructed with the prefix 'ch'. Then, the
+ channel number as specified in the documentation of the SoC. Finally,
+ the letter 'i' if the interrupt is raised by the IICR register. Or 'e'
+ if it is raised by the EICR register.
+
+ "#hwlock-cells":
+ const: 1
+
+ "#mbox-cells":
+ const: 2
+ description:
+ The first cell is the channel number as specified in the documentation
+ of the SoC. The second cell may specify flags as described in the file
+ <dt-bindings/mailbox/renesas,r8a78000-mfis.h>.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - "#hwlock-cells"
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mfis: syscon@189e0000 {
+ compatible = "renesas,r8a78000-mfis";
+ reg = <0x189e0000 0x1000>, <0x18800000 0x40000>;
+ reg-names = "common", "mboxes";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ch0i", "ch0e", "ch1i", "ch1e", "ch2i", "ch2e", "ch3i", "ch3e",
+ "ch4i", "ch4e", "ch5i", "ch5e", "ch6i", "ch6e", "ch7i", "ch7e",
+ "ch8i", "ch8e", "ch9i", "ch9e", "ch10i", "ch10e", "ch11i", "ch11e",
+ "ch12i", "ch12e", "ch13i", "ch13e", "ch14i", "ch14e", "ch15i", "ch15e",
+ "ch16i", "ch16e", "ch17i", "ch17e", "ch18i", "ch18e", "ch19i", "ch19e",
+ "ch20i", "ch20e", "ch21i", "ch21e", "ch22i", "ch22e", "ch23i", "ch23e",
+ "ch24i", "ch24e", "ch25i", "ch25e", "ch26i", "ch26e", "ch27i", "ch27e",
+ "ch28i", "ch28e", "ch29i", "ch29e", "ch30i", "ch30e", "ch31i", "ch31e",
+ "ch32i", "ch32e", "ch33i", "ch33e", "ch34i", "ch34e", "ch35i", "ch35e",
+ "ch36i", "ch36e", "ch37i", "ch37e", "ch38i", "ch38e", "ch39i", "ch39e",
+ "ch40i", "ch40e", "ch41i", "ch41e", "ch42i", "ch42e", "ch43i", "ch43e",
+ "ch44i", "ch44e", "ch45i", "ch45e", "ch46i", "ch46e", "ch47i", "ch47e",
+ "ch48i", "ch48e", "ch49i", "ch49e", "ch50i", "ch50e", "ch51i", "ch51e",
+ "ch52i", "ch52e", "ch53i", "ch53e", "ch54i", "ch54e", "ch55i", "ch55e",
+ "ch56i", "ch56e", "ch57i", "ch57e", "ch58i", "ch58e", "ch59i", "ch59e",
+ "ch60i", "ch60e", "ch61i", "ch61e", "ch62i", "ch62e", "ch63i", "ch63e";
+ #hwlock-cells = <1>;
+ #mbox-cells = <2>;
+ };
diff --git a/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
new file mode 100644
index 000000000000..89489c2a4847
--- /dev/null
+++ b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Constants for the mailbox part of the Renesas MFIS IP core.
+ */
+
+#ifndef _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
+#define _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
+
+/*
+ * MFIS HW design before r8a78001 requires a channel to be marked as either
+ * TX or RX.
+ */
+#define MFIS_CHANNEL_TX (0 << 0)
+#define MFIS_CHANNEL_RX (1 << 0)
+
+/*
+ * MFIS variants before r8a78001 work with pairs of IICR and EICR registers.
+ * Usually, it is specified in the datasheets which of the two a specific core
+ * should use. Then, it does not need extra description in DT. For plain MFIS
+ * of r8a78000, this is selectable, though. According to the system design and
+ * the firmware in use, these channels need to be marked. This is not needed
+ * with other versions of the MFIS, not even with MFIS-SCP of r8a78000.
+ */
+#define MFIS_CHANNEL_IICR (0 << 1)
+#define MFIS_CHANNEL_EICR (1 << 1)
+
+#endif
--
2.51.0
Hi Wolfram,
On Tue, 17 Mar 2026 at 14:06, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> Add device tree bindings for the Renesas Multifunctional Interface
> (MFIS) as found on the Renesas R-Car X5H (r8a78000) SoC. MFIS includes
> features like Mailbox/HW Spinlock/Product Register.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
> @@ -0,0 +1,160 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/renesas/renesas,r8a78000-mfis.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas MFIS (Multifunctional Interface) controller
> +
> +maintainers:
> + - Wolfram Sang <wsa+renesas@sang-engineering.com>
> +
> +description:
> + Renesas Multifunctional Interface (MFIS) provides functionality for
The Renesas Multifunctional Interface ...
> + communication between different CPU cores. Those cores can be in various
> + domains like AP, RT, or SCP. Functionality includes features like
> + mailboxes, hardware spinlocks and such.
> +
> +properties:
> + compatible:
> + enum:
> + - renesas,r8a78000-mfis # R-Car X5H (AP<->AP, with PRR)
> + - renesas,r8a78000-mfis-scp # R-Car X5H (AP<->SCP, without PRR)
[...]
> + interrupts:
> + minItems: 32
> + maxItems: 128
> + description:
> + The interrupts raised by the remote doorbells.
> +
> + interrupt-names:
> + minItems: 32
> + maxItems: 128
> + items:
> + pattern: "^ch[0-9]+[ie]$"
> + description:
> + An interrupt name is constructed with the prefix 'ch'. Then, the
> + channel number as specified in the documentation of the SoC. Finally,
> + the letter 'i' if the interrupt is raised by the IICR register. Or 'e'
> + if it is raised by the EICR register.
maxItems could be moved to a conditional schema, based on the compatible
value.
The same is true for the pattern rule, as MFIS has both "i" and "e"
interrupts, while MFIS-SCP has only the "i" variants.
> --- /dev/null
> +++ b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Constants for the mailbox part of the Renesas MFIS IP core.
> + */
> +
> +#ifndef _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
> +#define _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
The include protection does not match the filename.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Mar 17, 2026 at 02:06:34PM +0100, Wolfram Sang wrote: > Add device tree bindings for the Renesas Multifunctional Interface > (MFIS) as found on the Renesas R-Car X5H (r8a78000) SoC. MFIS includes > features like Mailbox/HW Spinlock/Product Register. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > Checked with 'dt_bindings_check'. Family-compatible values are not > introduced here because MFIS is usually very different per SoC. Ah, also, you hit 2/3 combo in your subject. You only need third for the bingo - YAML. A nit, subject: drop second/last, redundant "binding documentation". The "dt-bindings" prefix is already stating that these are bindings and documentation. See also: https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 Best regards, Krzysztof
On Tue, Mar 17, 2026 at 02:06:34PM +0100, Wolfram Sang wrote:
> Add device tree bindings for the Renesas Multifunctional Interface
> (MFIS) as found on the Renesas R-Car X5H (r8a78000) SoC. MFIS includes
> features like Mailbox/HW Spinlock/Product Register.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Checked with 'dt_bindings_check'. Family-compatible values are not
> introduced here because MFIS is usually very different per SoC.
Not sure with what family this would be compatible, but anyway this
should be explained in commit msg.
>
> .../soc/renesas/renesas,r8a78000-mfis.yaml | 160 ++++++++++++++++++
> .../mailbox/renesas,r8a78000-mfis.h | 27 +++
> 2 files changed, 187 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
> create mode 100644 include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
>
> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
> new file mode 100644
> index 000000000000..dbda28ac781c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
> @@ -0,0 +1,160 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/renesas/renesas,r8a78000-mfis.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas MFIS (Multifunctional Interface) controller
> +
> +maintainers:
> + - Wolfram Sang <wsa+renesas@sang-engineering.com>
> +
> +description:
> + Renesas Multifunctional Interface (MFIS) provides functionality for
> + communication between different CPU cores. Those cores can be in various
so kind of remoteproc? The soc directory is dumping ground, so you
should find something more suitable if possible.
> + domains like AP, RT, or SCP. Functionality includes features like
> + mailboxes, hardware spinlocks and such.
> +
> +properties:
> + compatible:
> + enum:
> + - renesas,r8a78000-mfis # R-Car X5H (AP<->AP, with PRR)
> + - renesas,r8a78000-mfis-scp # R-Car X5H (AP<->SCP, without PRR)
> +
> + reg:
> + minItems: 2
Drop
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: common
> + - const: mboxes
> +
> + interrupts:
> + minItems: 32
> + maxItems: 128
> + description:
> + The interrupts raised by the remote doorbells.
> +
> + interrupt-names:
> + minItems: 32
> + maxItems: 128
> + items:
> + pattern: "^ch[0-9]+[ie]$"
> + description:
> + An interrupt name is constructed with the prefix 'ch'. Then, the
> + channel number as specified in the documentation of the SoC. Finally,
> + the letter 'i' if the interrupt is raised by the IICR register. Or 'e'
> + if it is raised by the EICR register.
Describe why is this flexible. These are fixed devices, very specific
SoCs. They do not come with randomly routed interrupts, usually.
> +
> + "#hwlock-cells":
> + const: 1
> +
> + "#mbox-cells":
> + const: 2
> + description:
> + The first cell is the channel number as specified in the documentation
> + of the SoC. The second cell may specify flags as described in the file
> + <dt-bindings/mailbox/renesas,r8a78000-mfis.h>.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - interrupt-names
> + - "#hwlock-cells"
> + - "#mbox-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + mfis: syscon@189e0000 {
Drop label and rename node - that's not syscon.
> + compatible = "renesas,r8a78000-mfis";
> + reg = <0x189e0000 0x1000>, <0x18800000 0x40000>;
> + reg-names = "common", "mboxes";
> + interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "ch0i", "ch0e", "ch1i", "ch1e", "ch2i", "ch2e", "ch3i", "ch3e",
> + "ch4i", "ch4e", "ch5i", "ch5e", "ch6i", "ch6e", "ch7i", "ch7e",
> + "ch8i", "ch8e", "ch9i", "ch9e", "ch10i", "ch10e", "ch11i", "ch11e",
> + "ch12i", "ch12e", "ch13i", "ch13e", "ch14i", "ch14e", "ch15i", "ch15e",
> + "ch16i", "ch16e", "ch17i", "ch17e", "ch18i", "ch18e", "ch19i", "ch19e",
> + "ch20i", "ch20e", "ch21i", "ch21e", "ch22i", "ch22e", "ch23i", "ch23e",
> + "ch24i", "ch24e", "ch25i", "ch25e", "ch26i", "ch26e", "ch27i", "ch27e",
> + "ch28i", "ch28e", "ch29i", "ch29e", "ch30i", "ch30e", "ch31i", "ch31e",
> + "ch32i", "ch32e", "ch33i", "ch33e", "ch34i", "ch34e", "ch35i", "ch35e",
> + "ch36i", "ch36e", "ch37i", "ch37e", "ch38i", "ch38e", "ch39i", "ch39e",
> + "ch40i", "ch40e", "ch41i", "ch41e", "ch42i", "ch42e", "ch43i", "ch43e",
> + "ch44i", "ch44e", "ch45i", "ch45e", "ch46i", "ch46e", "ch47i", "ch47e",
> + "ch48i", "ch48e", "ch49i", "ch49e", "ch50i", "ch50e", "ch51i", "ch51e",
> + "ch52i", "ch52e", "ch53i", "ch53e", "ch54i", "ch54e", "ch55i", "ch55e",
> + "ch56i", "ch56e", "ch57i", "ch57e", "ch58i", "ch58e", "ch59i", "ch59e",
> + "ch60i", "ch60e", "ch61i", "ch61e", "ch62i", "ch62e", "ch63i", "ch63e";
> + #hwlock-cells = <1>;
> + #mbox-cells = <2>;
> + };
> diff --git a/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
> new file mode 100644
> index 000000000000..89489c2a4847
> --- /dev/null
> +++ b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Constants for the mailbox part of the Renesas MFIS IP core.
> + */
> +
> +#ifndef _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
> +#define _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
> +
> +/*
> + * MFIS HW design before r8a78001 requires a channel to be marked as either
> + * TX or RX.
> + */
> +#define MFIS_CHANNEL_TX (0 << 0)
0, bindings constants are abstract (so without dedicated meaning)
numbers, starting from 0 or 1 and incremented by 1. Shifting this
implies there is some other logic and that would mean - not a binding.
> +#define MFIS_CHANNEL_RX (1 << 0)
1
> +
> +/*
> + * MFIS variants before r8a78001 work with pairs of IICR and EICR registers.
> + * Usually, it is specified in the datasheets which of the two a specific core
> + * should use. Then, it does not need extra description in DT. For plain MFIS
> + * of r8a78000, this is selectable, though. According to the system design and
> + * the firmware in use, these channels need to be marked. This is not needed
> + * with other versions of the MFIS, not even with MFIS-SCP of r8a78000.
> + */
> +#define MFIS_CHANNEL_IICR (0 << 1)
> +#define MFIS_CHANNEL_EICR (1 << 1)
Same here.
Best regards,
Krzysztof
Hi Krzysztof,
thanks for the review!
> >
> > Checked with 'dt_bindings_check'. Family-compatible values are not
> > introduced here because MFIS is usually very different per SoC.
>
> Not sure with what family this would be compatible, but anyway this
> should be explained in commit msg.
The family would be "rcar-gen5". It was a close call where to put this
paragraph. I can put it to the commit messge as well.
> > +description:
> > + Renesas Multifunctional Interface (MFIS) provides functionality for
> > + communication between different CPU cores. Those cores can be in various
>
> so kind of remoteproc? The soc directory is dumping ground, so you
> should find something more suitable if possible.
I did this. And this was the conclusion because the IP core *is* kind of
a "dumping ground". This paragraph currently might be biased by what we
want support in Linux as of now, like mailboxes and hwspinlock and
product register. But it actually can have more like boot status, error
injection, error detection... and who knows what will be added in the
future. Since DT is HW description, I will update this paragraph to
mention the extra MFIS features even if there is no Linux support
planned.
> > + reg:
> > + minItems: 2
>
> Drop
Ack.
> > + description:
> > + An interrupt name is constructed with the prefix 'ch'. Then, the
> > + channel number as specified in the documentation of the SoC. Finally,
> > + the letter 'i' if the interrupt is raised by the IICR register. Or 'e'
> > + if it is raised by the EICR register.
>
> Describe why is this flexible. These are fixed devices, very specific
> SoCs. They do not come with randomly routed interrupts, usually.
It is not flexible. The interrupts are static and so should be the
naming. The above paragraph aims to describe that. Let me cite part of
the example for "renesas,r8a78000-mfis" from below where all interrupts
(triggered by both, the IICR/EICR registers) are routed to the AP core
interrupt controller. Note the alternating 'i/e' pattern:
interrupt-names = "ch0i", "ch0e", "ch1i", "ch1e", "ch2i", "ch2e", "ch3i", "ch3e",
"ch4i", "ch4e", "ch5i", "ch5e", "ch6i", "ch6e", "ch7i", "ch7e",
...
In comparison, "renesas,r8a78000-mfis-scp" where only the interrupts
triggered by the IICR register are routed to the AP (the EICR interrupts
are routed to the firmware controller). 'i' pattern only:
interrupt-names = "ch0i", "ch1i", "ch2i", "ch3i", "ch4i", "ch5i", "ch6i", "ch7i",
"ch8i", "ch9i", "ch10i", "ch11i", "ch12i", "ch13i", "ch14i", "ch15i",
...
I think the above description is technically correct. Maybe it is not
easy to understand, though. One improvement I could think of: add the
SCP case to the example section as well, so the difference is more
obvious. Note: I decided to use 'pattern:' for describing the
interrupt-names to avoid 128 const entries for the IICR/EICR case, and
64 const entries per IICR-only or EICR-only case.
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + mfis: syscon@189e0000 {
>
> Drop label and rename node - that's not syscon.
Yes to drop label. Not sure about renaming the node. Given the above of
the "dumping ground IP core", it is way more of a syscon than of a
mailbox controller. If there is a better common name of such a device, I
don't know of it and couldn't find it when grepping around. "remoteproc"
might be somewhat closer but still...
> > diff --git a/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
> > new file mode 100644
> > index 000000000000..89489c2a4847
> > --- /dev/null
> > +++ b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
I am wondering now if this is the right place for the include file. My
original intention was that it should go to the mailbox-dir because it
handles only the mailbox-part (second #mbox-cell) of the MFIS. But
maybe all-in-one is better? Other flags are not in flight currently,
though.
> > +/*
> > + * MFIS HW design before r8a78001 requires a channel to be marked as either
> > + * TX or RX.
> > + */
> > +#define MFIS_CHANNEL_TX (0 << 0)
>
> 0, bindings constants are abstract (so without dedicated meaning)
> numbers, starting from 0 or 1 and incremented by 1. Shifting this
> implies there is some other logic and that would mean - not a binding.
I'll give in and do it. Using fixed numbers instead of bit numbers
sounds more error prone to me, though. But we don't need to discuss
this, I'll adapt.
And I will change the $subject, too.
Happy hacking,
Wolfram
Hi Krzysztof,
On Wed, 18 Mar 2026 at 10:17, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Mar 17, 2026 at 02:06:34PM +0100, Wolfram Sang wrote:
> > Add device tree bindings for the Renesas Multifunctional Interface
> > (MFIS) as found on the Renesas R-Car X5H (r8a78000) SoC. MFIS includes
> > features like Mailbox/HW Spinlock/Product Register.
> >
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
> > + "#hwlock-cells":
> > + const: 1
> > +
> > + "#mbox-cells":
> > + const: 2
> > + description:
> > + The first cell is the channel number as specified in the documentation
> > + of the SoC. The second cell may specify flags as described in the file
> > + <dt-bindings/mailbox/renesas,r8a78000-mfis.h>.
> > --- /dev/null
> > +++ b/include/dt-bindings/mailbox/renesas,r8a78000-mfis.h
> > @@ -0,0 +1,27 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +/*
> > + * Constants for the mailbox part of the Renesas MFIS IP core.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
> > +#define _DT_BINDINGS_MAILBOX_RENESAS_MFIS_H
> > +
> > +/*
> > + * MFIS HW design before r8a78001 requires a channel to be marked as either
> > + * TX or RX.
> > + */
> > +#define MFIS_CHANNEL_TX (0 << 0)
>
> 0, bindings constants are abstract (so without dedicated meaning)
> numbers, starting from 0 or 1 and incremented by 1. Shifting this
> implies there is some other logic and that would mean - not a binding.
>
> > +#define MFIS_CHANNEL_RX (1 << 0)
>
> 1
>
>
> > +
> > +/*
> > + * MFIS variants before r8a78001 work with pairs of IICR and EICR registers.
> > + * Usually, it is specified in the datasheets which of the two a specific core
> > + * should use. Then, it does not need extra description in DT. For plain MFIS
> > + * of r8a78000, this is selectable, though. According to the system design and
> > + * the firmware in use, these channels need to be marked. This is not needed
> > + * with other versions of the MFIS, not even with MFIS-SCP of r8a78000.
> > + */
> > +#define MFIS_CHANNEL_IICR (0 << 1)
> > +#define MFIS_CHANNEL_EICR (1 << 1)
>
> Same here.
These are flags as the documentation for the #mbox-cells property in the
bindings file states, to be ORed.
E.g. include/dt-bindings/i2c/i2c.h and include/dt-bindings/i3c/i3c.h
also use shifts to make this clear.
include/dt-bindings/gpio/gpio.h uses "Bit N express ..." comments instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 19/03/2026 09:54, Geert Uytterhoeven wrote: >> >>> + >>> +/* >>> + * MFIS variants before r8a78001 work with pairs of IICR and EICR registers. >>> + * Usually, it is specified in the datasheets which of the two a specific core >>> + * should use. Then, it does not need extra description in DT. For plain MFIS >>> + * of r8a78000, this is selectable, though. According to the system design and >>> + * the firmware in use, these channels need to be marked. This is not needed >>> + * with other versions of the MFIS, not even with MFIS-SCP of r8a78000. >>> + */ >>> +#define MFIS_CHANNEL_IICR (0 << 1) >>> +#define MFIS_CHANNEL_EICR (1 << 1) >> >> Same here. > > These are flags as the documentation for the #mbox-cells property in the > bindings file states, to be ORed. I did not get the driver so I cannot verify that. What sort of Linux ABI does this bind? Best regards, Krzysztof
> I did not get the driver so I cannot verify that. What sort of Linux ABI > does this bind? In case you mean this as unanswered questions to v1: This describes the device specific second mbox cell. Like Tegra does it here (even with shifts instead of plain numbers): include/dt-bindings/mailbox/tegra186-hsp.h But all this has been said before and you got the driver as well in v2. I really have no idea what is still missing?
On 31/03/2026 09:10, Wolfram Sang wrote: > >> I did not get the driver so I cannot verify that. What sort of Linux ABI >> does this bind? > > In case you mean this as unanswered questions to v1: This describes the > device specific second mbox cell. Like Tegra does it here (even with > shifts instead of plain numbers): > > include/dt-bindings/mailbox/tegra186-hsp.h > > But all this has been said before and you got the driver as well in v2. > I really have no idea what is still missing? And look when my question was asked: 19th of Match: "I did not get the driver so I cannot verify that. What sort of Linux ABI does this bind?" You ignore it and on 23rd of Match you send v2. And now you reply that "you got driver as well in v2". Seriously? How can I move from 19th Match into the future of 23rd to get the email from the future? And some answers from the future? Respond to review instead of ignoring it and sending v2. Best regards, Krzysztof
> And look when my question was asked: > 19th of Match: > "I did not get the driver so I cannot verify that. What sort of Linux > ABI does this bind?" > > You ignore it and on 23rd of Match you send v2. The opposite is true. I saw it as a short-coming of v1 that you didn't get the driver to properly review it. So, like many other short-comings of v1, I addressed it in v2. I explicitly paid attention to send the driver in v2 to you and explain more of my reasoning to continue the discussion then on a better ground. This is exactly *not ignoring*! > And now you reply that "you got driver as well in v2". Seriously? How > can I move from 19th Match into the future of 23rd to get the email from > the future? And some answers from the future? You can't. But why can't we move the discussion to v2 instead? There is more context. This seems like absolutely normal development to me. > Respond to review instead of ignoring it and sending v2. Again, it was not ignoring. I even explained in v2 why I kept some choices as in v1. Might still be wrong, could be. But I tried to address the comments as best as I could.
On 31/03/2026 09:10, Wolfram Sang wrote: > >> I did not get the driver so I cannot verify that. What sort of Linux ABI >> does this bind? > > In case you mean this as unanswered questions to v1: This describes the > device specific second mbox cell. Like Tegra does it here (even with I asked Linux ABI. Device specific numbers is not Linux ABI, because Linux is not device. > shifts instead of plain numbers): > > include/dt-bindings/mailbox/tegra186-hsp.h > > But all this has been said before and you got the driver as well in v2. What do you mean by v2? This is v1, there cannot have been a v2. No changelog in cover letter, no references. > I really have no idea what is still missing? It's not a binding, drop the header from the bindings. Best regards, Krzysztof
> > In case you mean this as unanswered questions to v1: This describes the > > device specific second mbox cell. Like Tegra does it here (even with > > I asked Linux ABI. Device specific numbers is not Linux ABI, because > Linux is not device. I have no idea what you want here. I see it like this: DT is OS agnostic. So, the flags are to describe the hardware. The Linux driver then does the proper things according to these flags. Other OS driver might do other things. > > shifts instead of plain numbers): > > > > include/dt-bindings/mailbox/tegra186-hsp.h And I still have no idea why my header is different than the Tegra one. > > I really have no idea what is still missing? > > It's not a binding, drop the header from the bindings. So, I should add the header to the driver? Can do, but then I have to remove the reference to the header from the binding doc. Namely, this paragraph: + The first cell is the channel number as specified in the documentation + of the SoC. The second cell may specify flags as described in the file + <dt-bindings/soc/renesas,r8a78000-mfis.h>. Not helpful for the user, or?
On 31/03/2026 09:40, Wolfram Sang wrote: > >>> In case you mean this as unanswered questions to v1: This describes the >>> device specific second mbox cell. Like Tegra does it here (even with >> >> I asked Linux ABI. Device specific numbers is not Linux ABI, because >> Linux is not device. > > I have no idea what you want here. I see it like this: DT is OS DT, but we talk about bindings. Bindings is not DT. Bindings bind the SW and DTS. > agnostic. So, the flags are to describe the hardware. The Linux driver Well, then no. Bindings headers do not describe the hardware. > then does the proper things according to these flags. Other OS driver > might do other things. > >>> shifts instead of plain numbers): >>> >>> include/dt-bindings/mailbox/tegra186-hsp.h > > And I still have no idea why my header is different than the Tegra one. > No clue what is there. I am not going even to investigate, because this is argument of "I found a bug somewhere, so I can implement same bug". I responded to this *MULTIPLE* times already on the lists. I explained the rationale, I even provided old messages from Arnd and other people. Best regards, Krzysztof
On 18/03/2026 10:17, Krzysztof Kozlowski wrote: >> + >> +title: Renesas MFIS (Multifunctional Interface) controller >> + >> +maintainers: >> + - Wolfram Sang <wsa+renesas@sang-engineering.com> >> + >> +description: >> + Renesas Multifunctional Interface (MFIS) provides functionality for >> + communication between different CPU cores. Those cores can be in various > > so kind of remoteproc? The soc directory is dumping ground, so you > should find something more suitable if possible. or mailbox? Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.