On Sat, Aug 2, 2025 at 9:42 AM Samuel Holland <samuel.holland@sifive.com> wrote:
>
> Hi Anup,
>
> On 2025-07-28 4:40 AM, Anup Patel wrote:
> > Add device tree bindings for the RISC-V SBI Message Proxy (MPXY)
> > extension as a mailbox controller.
> >
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> > ---
> > .../bindings/mailbox/riscv,sbi-mpxy-mbox.yaml | 51 +++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml b/Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml
> > new file mode 100644
> > index 000000000000..061437a0b45a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mailbox/riscv,sbi-mpxy-mbox.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V SBI Message Proxy (MPXY) extension based mailbox
> > +
> > +maintainers:
> > + - Anup Patel <anup@brainfault.org>
> > +
> > +description: |
> > + The RISC-V SBI Message Proxy (MPXY) extension [1] allows supervisor
> > + software to send messages through the SBI implementation (M-mode
> > + firmware or HS-mode hypervisor). The underlying message protocol
> > + and message format used by the supervisor software could be some
> > + other standard protocol compatible with the SBI MPXY extension
> > + (such as RISC-V Platform Management Interface (RPMI) [2]).
> > +
> > + ===========================================
> > + References
> > + ===========================================
> > +
> > + [1] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
> > + https://github.com/riscv-non-isa/riscv-sbi-doc/releases
> > +
> > + [2] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
> > + https://github.com/riscv-non-isa/riscv-rpmi/releases
> > +
> > +properties:
> > + compatible:
> > + const: riscv,sbi-mpxy-mbox
> > +
> > + "#mbox-cells":
> > + const: 2
> > + description:
> > + The first cell specifies channel_id of the SBI MPXY channel,
> > + the second cell specifies MSG_PROT_ID of the SBI MPXY channel
>
> What is the purpose of the second mailbox cell?
>
> The client can probe the message protocol using a SBI call, if it doesn't just
> assume a protocol based on the kind of node that references this mailbox. The
> SBI implementation knows the message protocol from the kind of node that
> instantiates the channel (for example riscv,rpmi-mpxy-clock has
> riscv,sbi-mpxy-channel-id). So this cell looks redundant.
It is the SBI MPXY mailbox controller driver which does SBI calls
and not the RPMI client driver. The RPMI client driver (for example
RPMI clock driver) only xfer RPMI messages so it only needs mailbox
channels bound to RPMI protocol. This way same RPMI client driver
will work for both SBI MPXY mailbox controller driver and RPMI shared
memory mailbox controller driver.
(NOTE: RPMI shared memory mailbox controller driver is currently
not available for Linux.)
The SBI MPXY mailbox controller driver provides mailbox channels
for RPMI protocol and other custom message protocols as well so
if a RPMI mailbox client request a mailbox channel bound to some
other protocol then such a mailbox channel request should fail. To
achieve this, we have a second mailbox cell for mailbox channels
provided by SBI MPXY mailbox controller driver which specifies the
expected message protocol ID for the mailbox channel.
On other hand, the RPMI shared memory mailbox controller driver
will only provide mailbox channels bound to RPMI protocol and
not any other message protocol so for such mailbox channels we
only need one mailbox cell which specifies the service group ID.
Regards,
Anup