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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 02/09/2026 13:30, Joshua Yeong wrote:
> On Mon, Aug 31, 2026 at 11:38:07AM +0200, Krzysztof Kozlowski <krzk@kernel.org> 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@starfivetech.com>
>>> +
>>> +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.

> 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:


>             };
>     };
> 
>     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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv