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

From: Krzysztof Kozlowski

Date: Fri Sep 25 2026 - 02:08:02 EST


On 25/09/2026 04:21, Joshua Yeong wrote:
> On Thu, Sep 24, 2026 at 10:00:06PM +0100, Mark Brown <broonie@xxxxxxxxxx> 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.


As discussed on IRC #devicetree, that's either power-domains or
regulator supplies. If you need anything else, you need to explain. Not we.

Best regards,
Krzysztof