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

[Joshua Yeong]

Sorry I miss out on your feedback.

On Thu, Sep 3, 2026 at 08:39:33AM +0200, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> On 02/09/2026 13:30, Joshua Yeong wrote:
> > 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
>
> But SBI MPXY is also a mailbox, so you are encoding mailbox channel with
> a different property.

It is, but this node is on the provider side of that mailbox. It is
consumed by the SBI implementation. It takes RPMI service group 0x9
on this transport and expose it to the supervisor as SBI MPXY channel
0x1002. "mboxes" is the transport it consumes, the channel id is the
channel it creates, so it cannot be a phandle.

The SBI implementation may be an HS-mode hypervisor rather than 
M-mode firmware, and then the two nodes are not in the same device
Tree. The provider is in the host DT, the consumer in the guest DT. 
The channel id is the pre-agreed handshake value between the two, 
assigned ahead of time so the guest DT points at the right channel either way.

>
> > 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>;
>
> ... so 0x1002 is:
>

This is an configurations that meant for SBI (Machine Mode in RISC-V),
like  TF-A mode in EL3 for ARM platform. It may not be expose to 
device tree on linux / client side.

>
> >             };
> >     };
> > 
> >     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>;
>
> exactly this, no?
>
> >             #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.
> > 
>
>
> Best regards,
> Krzysztof