Re: [PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: non-standard voltage-domains property bypasses regulator core
--

commit cdb8b44dd04ecd7ad4b4433307fcafbb4c92ff48
Author: Joshua Yeong <joshua.yeong@starfivetech.com>

dt-bindings: regulator: Add RPMI voltage service bindings

This commit adds device tree bindings for the RISC-V Platform Management
Interface (RPMI) voltage service group. It includes definitions for both the
supervisor-facing regulator controller and the SBI MPXY channel.

> 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 0000000000000..6334ebd31dc8c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/riscv,rpmi-voltage.yaml

[ ... ]

> +description: |

[ ... ]

> +  A consumer names a domain in one of two ways. The first is through a
> +  "<name>-supply" phandle to a child of the optional "regulators" container,
> +  whose "reg" is the domain's RPMI DOMAIN_ID. The second needs no child with
> +  "#voltage-domain-cells" on the provider, a consumer lists
> +  "voltage-domains = <&provider DOMAIN_ID>" and names each entry in
> +  "voltage-domain-names", the way it names a voltage power domain. Both
> +  properties belong to the consumer, so a consumer binding describes them
> +  itself:

[Severity: Medium]
Does this custom voltage-domains property fragment the generic device tree
regulator subsystem architecture?

The standard regulator framework strictly expects consumers to link via
<name>-supply = <&phandle> for hardware-agnostic interactions. By advising
downstream consumers to adopt a voltage-domains paradigm in this description
block, the binding subverts the core subsystem. This would force consumers
to rely on bespoke driver APIs instead of standard generic regulator
interactions.

[ ... ]

> +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.
> +
> +  "#voltage-domain-cells":
> +    const: 1
> +    description:
> +      Lets a consumer name a domain by its RPMI DOMAIN_ID, the single cell of
> +      a "voltage-domains" entry, without a child node for the domain.

[Severity: Medium]
Is it safe to redefine how consumers link to regulator providers using this
non-standard property?

This establishes the alternative linkage paradigm mentioned above, which the
core regulator subsystem cannot parse natively.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923070014.1340761-2-joshua.yeong@starfivetech.com?part=1