From: Sudeep Holla <sudeep.holla@arm.com>
To: David Collins <quic_collinsd@quicinc.com>
Cc: Rob Herring <robh+dt@kernel.org>, Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
devicetree@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>
Subject: Re: [PATCH v2 0/2] regulator: scmi: add support for registering SCMI regulators by name
Date: Tue, 22 Mar 2022 11:40:50 +0000 [thread overview]
Message-ID: <Yjm1wpcMZsZJJCuy@bogus> (raw)
In-Reply-To: <cover.1647909090.git.quic_collinsd@quicinc.com>
On Mon, Mar 21, 2022 at 05:47:18PM -0700, David Collins wrote:
> Add support to register SCMI regulator subnodes based on an SCMI
> Voltage Domain name specified via the "arm,scmi-domain-name" device
> tree property. In doing so, make the "reg" property optional with
> the constraint that at least one of "reg" or "arm,scmi-domain-name"
> must be specified. If both are specified, then both must match the
> Voltage Domain data exposed by the SCMI platform.
>
Since the SCMI specification allows discovery of names based on the
numbering scheme, we haven't added support for the name explicitly.
However, I have heard/received couple of such feedback to provide
name based access in private so far. So good to have this discussion
in public.
> Name based SCMI regulator registration helps ensure that an SCMI
> agent doesn't need to be aware of the numbering scheme used for
> Voltage Domains by the SCMI platform.
While I understand the regulator framework has a good support for name
based approach you prefer, I see other frameworks like clock rely on
numbering scheme and I see quite a few qualcomm platforms upstream use
the number scheme for clocks. So why is that a problem with regulator ?
Another main issue I have is what if the firmware and DT end up with a
mismatch say with a firmware upgrade or a DT update ? Basically out of sync
between DT and the SCMI firmware. I see this as duplication of source of
information and is always cause for the trouble. I don't want to end up with
the quirks to deal with (totally unnecessary) issues this may create in long
run.
> It also ensures that the
> correct Voltage Domain is selected for a given physical regulator.
How is that done magically if I give wrong regulator name ? Sorry the way
it is presented sounds like adding name fixes something that numerical
ID alone will always break.
> This cannot be guaranteed with numeric Voltage Domain IDs alone.
>
If the IDs are correct like the names, it is guaranteed. I see this
ID vs name is more for some maintenance convenience because somewhere
something else needs to changes or moved away from existing way of
maintenance.
That said, if others believe, this is useful, I am happy to consider
esp. if there are more *real* reasons for doing this.
Please add clock and other subsystem maintainers who also have numbering
scheme as main mechanism in the upstream so that we get feedback from them
too.
--
Regards,
Sudeep
next prev parent reply other threads:[~2022-03-22 11:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 0:47 [PATCH v2 0/2] regulator: scmi: add support for registering SCMI regulators by name David Collins
2022-03-22 0:47 ` [PATCH v2 1/2] dt-bindings: firmware: arm,scmi: define support for name based regulators David Collins
2022-03-22 11:40 ` Sudeep Holla [this message]
2022-03-23 1:12 ` [PATCH v2 0/2] regulator: scmi: add support for registering SCMI regulators by name David Collins
2022-03-24 17:23 ` Mark Brown
2022-03-25 10:35 ` Cristian Marussi
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=Yjm1wpcMZsZJJCuy@bogus \
--to=sudeep.holla@arm.com \
--cc=broonie@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_collinsd@quicinc.com \
--cc=quic_subbaram@quicinc.com \
--cc=robh+dt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).