[PATCH v5 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq

Marc Zyngier maz at kernel.org
Tue Nov 29 06:02:54 PST 2022


On 2022-11-29 11:36, Ulf Hansson wrote:
> On Mon, 28 Nov 2022 at 15:29, Hector Martin <marcan at 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 at 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...



More information about the linux-arm-kernel mailing list