From: Justin Chen <justin.chen@broadcom.com>
Add devicetree YAML binding for brcmstb bcm74110 mailbox used
for communicating with a co-processor.
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
---
v3
Added list for interrupts.
Corrected dts example. Fixed ordering and naming.
v2
Renamed brcm,brcm_{tx|rx} to brcm,{tx|rx}.
Removed brcm,shmem node. Not necessary to keep in dt.
Fixed example and added scmi node.
.../bindings/mailbox/brcm,bcm74110-mbox.yaml | 65 +++++++++++++++++++
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml
new file mode 100644
index 000000000000..d6084ed23126
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/brcm,bcm74110-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM74110 Mailbox
+
+maintainers:
+ - Justin Chen <justin.chen@broadcom.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+description: Broadcom mailbox hardware first introduced with 74110
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm74110-mbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: RX doorbell and watermark interrupts
+ - description: TX doorbell and watermark interrupts
+
+ "#mbox-cells":
+ const: 2
+ description:
+ The first cell is channel type and second cell is shared memory slot
+
+ brcm,rx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: RX Mailbox number
+
+ brcm,tx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TX Mailbox number
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+ - brcm,rx
+ - brcm,tx
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@a552000 {
+ compatible = "brcm,bcm74110-mbox";
+ reg = <0xa552000 0x1104>;
+ interrupts = <GIC_SPI 0x67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 0x66 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <0x2>;
+ brcm,rx = <0x7>;
+ brcm,tx = <0x6>;
+ };
--
2.34.1On 05/04/2025 00:20, justin.chen@broadcom.com wrote: > + > +maintainers: > + - Justin Chen <justin.chen@broadcom.com> > + - Florian Fainelli <florian.fainelli@broadcom.com> > + > +description: Broadcom mailbox hardware first introduced with 74110 > + > +properties: > + compatible: > + enum: > + - brcm,bcm74110-mbox > + > + reg: > + maxItems: 1 > + > + interrupts: > + minItems: 1 Third version of patchset, third entirely different code. Decide finally what is the hardware and send binding matching it. Hardware did not change last one week three times. Drop minItems or explain why this is flexible on the same SoC or between boards using same SoC. You can always point me to upstream DTS, which would solve many questions. > + items: > + - description: RX doorbell and watermark interrupts > + - description: TX doorbell and watermark interrupts > + Best regards, Krzysztof
On 4/6/25 5:27 AM, Krzysztof Kozlowski wrote:
> On 05/04/2025 00:20, justin.chen@broadcom.com wrote:
>> +
>> +maintainers:
>> + - Justin Chen <justin.chen@broadcom.com>
>> + - Florian Fainelli <florian.fainelli@broadcom.com>
>> +
>> +description: Broadcom mailbox hardware first introduced with 74110
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - brcm,bcm74110-mbox
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + minItems: 1
>
> Third version of patchset, third entirely different code.
>
> Decide finally what is the hardware and send binding matching it.
> Hardware did not change last one week three times.
>
> Drop minItems or explain why this is flexible on the same SoC or between
> boards using same SoC. You can always point me to upstream DTS, which
> would solve many questions.
>
We do not have an upstream DTS. We have a scripting engine that
generates a DTS and we distribute DTBs to our customers. The example
from v2 of my patch was copied from said generated DTS.
Apologies as I navigate through the different yaml keywords here. The HW
isn't changing, I am just struggling with representing the HW using the
different keywords. And the different implications of using said keywords.
Here is what I have for v4.
items:
- description: RX doorbell and watermark interrupts
- description: TX doorbell and watermark interrupts
+ description:
+ RX interrupts are required to notify the host of pending messages. TX
+ interrupts are optional. The TX doorbell interrupt is not used by the
+ host, but watermark interrupts may be used to notify a host
waiting on
+ a full out queue.
Thanks,
Justin
>> + items:
>> + - description: RX doorbell and watermark interrupts
>> + - description: TX doorbell and watermark interrupts
>> +
>
>
> Best regards,
> Krzysztof
On 07/04/2025 22:57, Justin Chen wrote: > from v2 of my patch was copied from said generated DTS. > > Apologies as I navigate through the different yaml keywords here. The HW > isn't changing, I am just struggling with representing the HW using the > different keywords. And the different implications of using said keywords. > > Here is what I have for v4. > items: > - description: RX doorbell and watermark interrupts > - description: TX doorbell and watermark interrupts > + description: > + RX interrupts are required to notify the host of pending messages. TX > + interrupts are optional. The TX doorbell interrupt is not used by the > + host, but watermark interrupts may be used to notify a host > waiting on > + a full out queue. What does it mean optional? Board decides on SoC connections? Given SoC is fixed isn't it? Best regards, Krzysztof
On 4/7/25 11:05 PM, Krzysztof Kozlowski wrote: > On 07/04/2025 22:57, Justin Chen wrote: > > >> from v2 of my patch was copied from said generated DTS. >> >> Apologies as I navigate through the different yaml keywords here. The HW >> isn't changing, I am just struggling with representing the HW using the >> different keywords. And the different implications of using said keywords. >> >> Here is what I have for v4. >> items: >> - description: RX doorbell and watermark interrupts >> - description: TX doorbell and watermark interrupts >> + description: >> + RX interrupts are required to notify the host of pending messages. TX >> + interrupts are optional. The TX doorbell interrupt is not used by the >> + host, but watermark interrupts may be used to notify a host >> waiting on >> + a full out queue. > What does it mean optional? Board decides on SoC connections? Given SoC > is fixed isn't it? > Maybe I misunderstand optional here. We have optional from the SoC perspective and optional from a driver perspective. I was thinking if we have a HW feature that the software may choose to use, it is considered optional. If that is not the correct understanding, I can make adjustments. I will remove minItems, which from understanding, means both IRQs are required. Thanks, Justin > Best regards, > Krzysztof
On 10/04/2025 20:44, Justin Chen wrote: > > > On 4/7/25 11:05 PM, Krzysztof Kozlowski wrote: >> On 07/04/2025 22:57, Justin Chen wrote: >> >> >>> from v2 of my patch was copied from said generated DTS. >>> >>> Apologies as I navigate through the different yaml keywords here. The HW >>> isn't changing, I am just struggling with representing the HW using the >>> different keywords. And the different implications of using said keywords. >>> >>> Here is what I have for v4. >>> items: >>> - description: RX doorbell and watermark interrupts >>> - description: TX doorbell and watermark interrupts >>> + description: >>> + RX interrupts are required to notify the host of pending messages. TX >>> + interrupts are optional. The TX doorbell interrupt is not used by the >>> + host, but watermark interrupts may be used to notify a host >>> waiting on >>> + a full out queue. >> What does it mean optional? Board decides on SoC connections? Given SoC >> is fixed isn't it? >> > > Maybe I misunderstand optional here. We have optional from the SoC > perspective and optional from a driver perspective. I was thinking if we > have a HW feature that the software may choose to use, it is considered > optional. If that is not the correct understanding, I can make Both meanings are considered. Optional for driver means hardware has it but also has default values and driver implementations can work without it on these defaults, e.g. some property configuring registers like min/max regulator voltages. Optional for hardware means it can really be "not connected" on some hardwares/boards, e.g. some pins are grounded. The "interrupts" do not really fit into the first category, so they could be optional only if your hardware really allows this interrupt to be missing (or such hardware exists). > adjustments. I will remove minItems, which from understanding, means > both IRQs are required. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.