[PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings
Joshua Yeong
joshua.yeong at starfivetech.com
Thu Sep 24 19:21:51 PDT 2026
On Thu, Sep 24, 2026 at 10:00:06PM +0100, Mark Brown <broonie at kernel.org> wrote:
> On Wed, Sep 23, 2026 at 10:35:08PM +0200, Krzysztof Kozlowski wrote:
> > On 23/09/2026 09:00, Joshua Yeong wrote:
>
> > > + voltage-service {
>
> > There is no such service. Don't invent names. See DT spec.
>
> Looks like it comes from the RPMI spec:
>
>
> https://github.com/riscv-non-isa/riscv-rpmi/blob/main/src/srvgrp-volta
> ge.adoc
>
> > > + "#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:
>
> > And where do you explain what is that "voltage domain" and why it is
> > completely different than everything else we have?
>
> > No, don't come up with your own naming for standard things.
>
> That also looks like what the spec says (some of the description is
> copied pretty closely from the spec).
The RPMI specification uses the word voltage instead of 'regulator' in the
kernel here. We need something like power-domain-cells,
performance-domain-cells or clock-cells that isn't supported by regulator
framework. While I have no prior history on the regulator framework but
the RPMI voltage service drivers trying to upstream here need some
mechanism to map just the domain id to the RPMI services.
The driver would still work with the existing voltage device tree structure.
I understand other drivers may not use voltage-domain like RPMI
voltage service, so I only add the support for this on the RPMI
voltage driver and not on the framework side.
More information about the linux-riscv
mailing list