From: Krzysztof Kozlowski <krzk@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Joshua Yeong <joshua.yeong@starfivetech.com>,
lgirdwood@gmail.com, rahul@summations.net, anup@brainfault.org,
lftan.linux@gmail.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings
Date: Fri, 25 Sep 2026 08:11:54 +0200 [thread overview]
Message-ID: <48ba811e-e293-4e94-af38-5cdae4562739@kernel.org> (raw)
In-Reply-To: <c2c57bf0-e610-4353-93a4-84edfd08e767@sirena.org.uk>
On 24/09/2026 23:00, Mark Brown wrote:
> On Wed, Sep 23, 2026 at 10:35:08PM +0200, Krzysztof Kozlowski wrote:
>>> + "#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).
I think we should not create complete new bindings for one spec, but
rather map that spec to existing code.
Best regards,
Krzysztof
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Joshua Yeong <joshua.yeong@starfivetech.com>,
lgirdwood@gmail.com, rahul@summations.net, anup@brainfault.org,
lftan.linux@gmail.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings
Date: Fri, 25 Sep 2026 08:11:54 +0200 [thread overview]
Message-ID: <48ba811e-e293-4e94-af38-5cdae4562739@kernel.org> (raw)
In-Reply-To: <c2c57bf0-e610-4353-93a4-84edfd08e767@sirena.org.uk>
On 24/09/2026 23:00, Mark Brown wrote:
> On Wed, Sep 23, 2026 at 10:35:08PM +0200, Krzysztof Kozlowski wrote:
>>> + "#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).
I think we should not create complete new bindings for one spec, but
rather map that spec to existing code.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-09-25 6:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 7:00 [PATCH v2 0/3] Add RISC-V RPMI voltage service support Joshua Yeong
2026-09-23 7:00 ` Joshua Yeong
2026-09-23 7:00 ` [PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings Joshua Yeong
2026-09-23 7:00 ` Joshua Yeong
2026-09-23 7:25 ` sashiko-bot
2026-09-23 20:35 ` Krzysztof Kozlowski
2026-09-23 20:35 ` Krzysztof Kozlowski
2026-09-24 21:00 ` Mark Brown
2026-09-24 21:00 ` Mark Brown
2026-09-25 2:21 ` Joshua Yeong
2026-09-25 2:21 ` Joshua Yeong
2026-09-25 6:07 ` Krzysztof Kozlowski
2026-09-25 6:07 ` Krzysztof Kozlowski
2026-09-25 7:14 ` Joshua Yeong
2026-09-25 7:14 ` Joshua Yeong
2026-09-25 15:18 ` Krzysztof Kozlowski
2026-09-25 15:18 ` Krzysztof Kozlowski
2026-09-25 17:15 ` Mark Brown
2026-09-25 17:15 ` Mark Brown
2026-09-26 21:21 ` Conor Dooley
2026-09-26 21:21 ` Conor Dooley
2026-09-27 6:37 ` Joshua Yeong
2026-09-27 6:37 ` Joshua Yeong
2026-09-25 17:20 ` Mark Brown
2026-09-25 17:20 ` Mark Brown
2026-09-25 6:11 ` Krzysztof Kozlowski [this message]
2026-09-25 6:11 ` Krzysztof Kozlowski
2026-09-25 17:25 ` Mark Brown
2026-09-25 17:25 ` Mark Brown
2026-09-23 7:00 ` [PATCH v2 2/3] regulator: Add RPMI voltage service Joshua Yeong
2026-09-23 7:00 ` Joshua Yeong
2026-09-23 7:29 ` sashiko-bot
2026-09-23 7:00 ` [PATCH v2 3/3] MAINTAINERS: Add RISC-V RPMI voltage driver Joshua Yeong
2026-09-23 7:00 ` Joshua Yeong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48ba811e-e293-4e94-af38-5cdae4562739@kernel.org \
--to=krzk@kernel.org \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=joshua.yeong@starfivetech.com \
--cc=krzk+dt@kernel.org \
--cc=lftan.linux@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rahul@summations.net \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.