On Wed, Oct 07, 2026 at 06:00:18PM +0800, Joshua Yeong wrote:
> Add device tree bindings for the RISC-V Platform Management Interface
> (RPMI) voltage service group, both for the supervisor-facing regulator
> controller and for the SBI MPXY channel which the SBI implementation
> uses to expose the service group.
> 
> Signed-off-by: Joshua Yeong <joshua.yeong@starfivetech.com>
> ---
> Based on the RPMI device power series ("Add RISC-V RPMI device power
> service support"), which has been applied for next. The cover letter
> links the mail saying so.

What actual basis on that does this patch have?
It's just the same pattern, but this pattern applies to clks etc etc
too.

> diff --git a/Documentation/devicetree/bindings/regulator/riscv,rpmi-voltage.yaml b/Documentation/devicetree/bindings/regulator/riscv,rpmi-voltage.yaml
> new file mode 100644
> index 000000000000..3be47703af5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/riscv,rpmi-voltage.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/riscv,rpmi-voltage.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V RPMI voltage service group based regulator controller
> +
> +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 voltage service group for accessing
> +  and controlling the voltage domains managed by a platform
> +  microcontroller. The supervisor software can access RPMI voltage
> +  service group via SBI MPXY channel or some dedicated supervisor-mode
> +  RPMI transport.
> +
> +  The voltage domains are discovered at runtime from the platform
> +  microcontroller, which reports the name, the level format, the supported
> +  levels and the always-on capability of each one, so none of that is
> +  described here.
> +
> +  A consumer names a domain through a "<name>-supply" phandle to a child of
> +  the optional "regulators" container, whose "reg" is the domain's RPMI
> +  DOMAIN_ID. A domain without such a child is still registered, but has no
> +  node for a consumer to point at:
> +
> +    codec {
> +            compatible = "vendor,codec";
> +            vdd-supply = <&volt2_reg>;
> +    };
> +
> +  A child may also say what the board permits the rail to supply, which the
> +  platform microcontroller has no way to express. A child that gives no
> +  voltage constraint leaves the rail free to move within the levels the
> +  domain advertises.
> +
> +  ===========================================
> +  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 supervisor software.
> +    const: riscv,rpmi-voltage
> +
> +  mboxes:
> +    maxItems: 1
> +    description:
> +      Mailbox channel of the underlying RPMI transport or SBI message proxy channel.
> +
> +  regulators:
> +    type: object
> +    additionalProperties: false
> +    description:
> +      Optional container giving discovered domains a node of their own, for
> +      consumers to reference and for board level constraints.
> +
> +    properties:
> +      "#address-cells":
> +        const: 1
> +
> +      "#size-cells":
> +        const: 0
> +
> +    patternProperties:
> +      "^regulator@[0-9a-f]+$":
> +        type: object
> +        $ref: regulator.yaml#
> +        unevaluatedProperties: false
> +
> +        properties:
> +          reg:
> +            maxItems: 1
> +            description:
> +              RPMI DOMAIN_ID of the voltage domain this node describes.
> +
> +        required:
> +          - reg
> +
> +    required:
> +      - "#address-cells"
> +      - "#size-cells"
> +
> +required:
> +  - compatible
> +  - mboxes
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    rpmi-voltage {
> +        compatible = "riscv,rpmi-voltage";
> +        mboxes = <&mpxy_mbox 0x1004 0x0>;
> +
> +        regulators {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            // A node only so that a consumer can name the domain with a
> +            // "<name>-supply". Its voltage stays free to move within the
> +            // advertised levels.

I think this is incorrectly worded. I think it should say something like
"A supply where the voltage is free to move within the levels advertised
by the domain". The "A node only" wording is just hard to understand.

> +            volt1_reg: regulator@1 {
> +                reg = <1>;
> +            };
> +
> +            // A board level constraint. Equal bounds pin the rail, so the
> +            // supervisor applies 1.8V and refuses to move it afterwards.

I'd skip the detail on how all regulators work, I'd rather "A supply
where board-level constraints apply in addition to those advertised by
the domain" or something like that.

Cheers,
Conor.

> +            volt2_reg: regulator@2 {
> +                reg = <2>;
> +                regulator-min-microvolt = <1800000>;
> +                regulator-max-microvolt = <1800000>;
> +            };
> +        };
> +    };
> +...
> -- 
> 2.43.0
>