[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