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

[Krzysztof Kozlowski <krzk@kernel.org>]

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


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