From: Marc Zyngier <maz@kernel.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Hector Martin <marcan@marcan.st>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Sven Peter <sven@svenpeter.dev>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq
Date: Tue, 29 Nov 2022 14:02:54 +0000 [thread overview]
Message-ID: <44c746aee96ebf13bd701d78f1c2b9c0@kernel.org> (raw)
In-Reply-To: <CAPDyKFobMvef_BWGMR=7avODh2r5XNMGpwO3xYgrN-u=DqRwbg@mail.gmail.com>
On 2022-11-29 11:36, Ulf Hansson wrote:
> On Mon, 28 Nov 2022 at 15:29, Hector Martin <marcan@marcan.st> wrote:
>>
>> +examples:
>> + - |
>> + // This example shows a single CPU per domain and 2 domains,
>> + // with two p-states per domain.
>> + // Shipping hardware has 2-4 CPUs per domain and 2-6 domains.
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + compatible = "apple,icestorm";
>> + device_type = "cpu";
>> + reg = <0x0 0x0>;
>> + operating-points-v2 = <&ecluster_opp>;
>
> To me, it looks like the operating-points-v2 phandle better belongs in
> the performance-domains provider node. I mean, isn't the OPPs really a
> description of the performance-domain provider?
>
> That said, I suggest we try to extend the generic performance-domain
> binding [1] with an "operating-points-v2". In that way, we should
> instead be able to reference it from this binding.
>
> In fact, that would be very similar to what already exists for the
> generic power-domain binding [2]. I think it would be rather nice to
> follow a similar pattern for the performance-domain binding.
I'm not going to rabbit-hole into whether this is a good
or a bad binding. As far as I'm concerned, and as a user
of the HW it describes, it does the job in a satisfactory
manner.
What I'm concerned about is that this constant, last minute
bikeshedding that actively prevents upstreaming of support
for HW that people are actively using.
If anything, this is only causing people to stop trying to
contribute to the upstream kernel because of this constant
DT bikeshed. Honestly, writing code to support this HW is
a lot less effort than trying to get 3 different people to
agree on a binding.
It also affects other OSs that rely on the the same bindings,
and will eventually only result in developers not submitting
bindings anymore. After all, nothing says that bindings and
device trees have to exist in the Linux kernel tree.
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2022-11-29 14:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 14:29 [PATCH v5 0/4] Apple SoC cpufreq driver Hector Martin
2022-11-28 14:29 ` [PATCH v5 1/4] MAINTAINERS: Add entries for " Hector Martin
2022-11-28 14:29 ` [PATCH v5 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq Hector Martin
2022-11-28 14:40 ` Krzysztof Kozlowski
2022-11-29 11:36 ` Ulf Hansson
2022-11-29 14:00 ` Hector Martin
2022-11-29 14:34 ` Krzysztof Kozlowski
2022-11-29 15:17 ` Hector Martin
2022-11-29 15:46 ` Krzysztof Kozlowski
2022-11-29 16:05 ` Hector Martin
2022-11-29 23:28 ` Rob Herring
2022-11-30 19:50 ` Rob Herring
2022-11-29 16:13 ` Ulf Hansson
2022-11-29 14:02 ` Marc Zyngier [this message]
2022-11-29 23:30 ` Rob Herring
2022-11-28 14:29 ` [PATCH v5 3/4] cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states Hector Martin
2022-11-30 5:43 ` Viresh Kumar
2022-11-28 14:29 ` [PATCH v5 4/4] arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103 Hector Martin
2022-11-30 5:45 ` [PATCH v5 0/4] Apple SoC cpufreq driver Viresh Kumar
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=44c746aee96ebf13bd701d78f1c2b9c0@kernel.org \
--to=maz@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=asahi@lists.linux.dev \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.kettenis@xs4all.nl \
--cc=matthias.bgg@gmail.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sven@svenpeter.dev \
--cc=ulf.hansson@linaro.org \
--cc=viresh.kumar@linaro.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).