RE: [PATCH v2 1/2] dt-bindings: power: Add RPMI device power service bindings

[Joshua Yeong]

On Mon, Aug 31, 2026 at 11:38:07AM +0200, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> On Sun, Aug 30, 2026 at 11:28:11PM +0800, Joshua Yeong wrote:
> > diff --git a/Documentation/devicetree/bindings/power/riscv,rpmi-mpxy-device-power.yaml b/Documentation/devicetree/bindings/power/riscv,rpmi-mpxy-device-power.yaml
> > new file mode 100644
> > index 000000000000..2b7df66ba172
>
> A nit, subject: drop second/last, redundant "bindings". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>

Ok, I will drop the redundant "bindings" word in v3.

> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/riscv,rpmi-mpxy-device-power.yaml
> > @@ -0,0 +1,65 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/power/riscv,rpmi-mpxy-device-power.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V RPMI device power service group based message proxy
> > +
> > +maintainers:
> > +  - Joshua Yeong <joshua.yeong@xxxxxxxxxxxxxxxx>
> > +
> > +description: |
> > +  The RISC-V Platform Management Interface (RPMI) [1] defines a
> > +  messaging protocol which is modular and extensible. The supervisor
> > +  software can send/receive RPMI messages via SBI MPXY extension [2]
> > +  or some dedicated supervisor-mode RPMI transport.
> > +
> > +  The RPMI specification [1] defines device power service group for
> > +  accessing and controlling the power state of platform devices managed
> > +  by a platform microcontroller. The SBI implementation (machine mode
> > +  firmware or hypervisor) can implement an SBI MPXY channel to allow RPMI
> > +  device power service group access to the supervisor software.
> > +
> > +  ===========================================
> > +  References
> > +  ===========================================
> > +
> > +  [1] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
> > +      https://github.com/riscv-non-isa/riscv-rpmi/releases
> > +
> > +  [2] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
> > +      https://github.com/riscv-non-isa/riscv-sbi-doc/releases
> > +
> > +properties:
> > +  compatible:
> > +    description:
> > +      Intended for use by the SBI implementation.
> > +    const: riscv,rpmi-mpxy-device-power
> > +
> > +  mboxes:
> > +    maxItems: 1
> > +    description:
> > +      Mailbox channel of the underlying RPMI transport.
> > +
> > +  riscv,sbi-mpxy-channel-id:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
>
> Why isn't this just phandle to mbox? Or even implied by mbox channel? As
> your example shows, having same value in two places points that it is
> redundant.
>

They look alike but they are in different namespaces, so the two values
are not the same number. In this node "mboxes" points at the RPMI shared
memory transport, whose #mbox-cells is 1 and whose cell is an RPMI
service group ID 0x9 for device power. "riscv,sbi-mpxy-channel-id" is
the SBI MPXY channel number that the SBI implementation then creates for
that service group. The node therefore describes a translation
rather than a duplication, consume RPMI service group 0x9 on the
transport and expose it to the supervisor as MPXY channel 0x1002.

The 0x1002 that does appear twice is spread over two nodes with two
different audiences, sitting under two different mailbox controllers:


    rpmi-shmem@12c10000 {            /* RISC-V machine mode only */
            compatible = "riscv,rpmi-shmem-mbox";
            reg = <...>;
            #mbox-cells = <1>;

            power-domain@9 {         /* read by the SBI implementation */
                    compatible = "riscv,rpmi-mpxy-device-power";
                    mboxes = <&rpmi_shmem 0x9>;
                    riscv,sbi-mpxy-channel-id = <0x1002>;
            };
    };

    sbi-mpxy-mbox {                  /* RISC-V supervisor mode only */
            compatible = "riscv,sbi-mpxy-mbox";
            #mbox-cells = <2>;       /* cells: channel_id, MSG_PROT_ID */
    };

    rpmi-device-power {              /* RISC-V supervisor mode only */
            compatible = "riscv,rpmi-device-power";
            mboxes = <&sbi_mpxy_mbox 0x1002 0x0>;
            #power-domain-cells = <1>;
    };

A phandle from the supervisor node to power-domain@9 would resolve its
"mboxes" to the shared memory transport, which is not something the
supervisor can drive. The windows are owned by machine mode and the
only RPMI mailbox Linux implements is "riscv,sbi-mpxy-mbox". The
supervisor reaches the platform controller through the SBI MPXY extension and
that ABI addresses channels by number, so the channel id has to survive
as a plain integer on both sides of the SBI boundary.

You can have a look at the diagram in RISC-V ratified specifications in
https://github.com/riscv-non-isa/riscv-rpmi/releases/tag/v1.0 -> riscv-rpmi.pdf
in Figure 2 High Level Architecture.

> > +    description:
> > +      The SBI MPXY channel id to be used for providing RPMI access to
> > +      the supervisor software.
> > +
> > +required:
> > +  - compatible
> > +  - mboxes
> > +  - riscv,sbi-mpxy-channel-id
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    device-power-service {
> > +        compatible = "riscv,rpmi-mpxy-device-power";
> > +        mboxes = <&rpmi_shmem_mbox 0x9>;
> > +        riscv,sbi-mpxy-channel-id = <0x1002>;
> > +    };
> > +...
> > -- 
> > 2.43.0
> >