linux-kernel - Re: [PATCH v4 1/2] dt-bindings: cpufreq: Document support for Airoha EN7581 CPUFreq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFo6j__CoReyAbeLJkA8JJQhJVc=umNesQRZKm-RxFHCwA@mail.gmail.com>
Date: Tue, 3 Dec 2024 11:33:28 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Rob Herring <robh@...nel.org>
Cc: Christian Marangi <ansuelsmth@...il.com>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Viresh Kumar <viresh.kumar@...aro.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, linux-pm@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, upstream@...oha.com
Subject: Re: [PATCH v4 1/2] dt-bindings: cpufreq: Document support for Airoha
 EN7581 CPUFreq

On Mon, 2 Dec 2024 at 21:57, Rob Herring <robh@...nel.org> wrote:
>
> On Mon, Dec 02, 2024 at 04:45:17PM +0100, Christian Marangi wrote:
> > On Mon, Dec 02, 2024 at 04:42:33PM +0100, Ulf Hansson wrote:
> > > On Mon, 2 Dec 2024 at 16:20, Christian Marangi <ansuelsmth@...il.com> wrote:
> > > >
> > > > Document required property for Airoha EN7581 CPUFreq .
> > > >
> > > > On newer Airoha SoC, CPU Frequency is scaled indirectly with SMCCC commands
> > > > to ATF and no clocks are exposed to the OS.
> > > >
> > > > The SoC have performance state described by ID for each OPP, for this a
> > > > Power Domain is used that sets the performance state ID according to the
> > > > required OPPs defined in the CPU OPP tables.
> > > >
> > > > Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> > > > ---
> > > > Changes v4:
> > > > - Add this patch
> > > >
> > > >  .../cpufreq/airoha,en7581-cpufreq.yaml        | 259 ++++++++++++++++++
> > > >  1 file changed, 259 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml
> > > > new file mode 100644
> > > > index 000000000000..a5bdea7f34b5
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml
> > >
> > > [...]
> > >
> > > > +examples:
> > > > +  - |
> > > > +    / {
> > > > +        #address-cells = <2>;
> > > > +       #size-cells = <2>;
> > > > +
> > > > +        cpus {
> > > > +            #address-cells = <1>;
> > > > +            #size-cells = <0>;
> > > > +
> > > > +            cpu0: cpu@0 {
> > > > +                device_type = "cpu";
> > > > +                compatible = "arm,cortex-a53";
> > > > +                reg = <0x0>;
> > > > +                operating-points-v2 = <&cpu_opp_table>;
> > > > +                enable-method = "psci";
> > > > +                clocks = <&cpufreq>;
> > > > +                clock-names = "cpu";
> > > > +                power-domains = <&cpufreq>;
> > > > +                power-domain-names = "cpu_pd";
> > >
> > > Nitpick: Perhaps clarify the name to be "perf" or "cpu_perf", to
> > > indicate it's a power-domain with performance scaling support.
> > >
> >
> > Will change to cpu_perf. Thanks a lot for the review!
>
> Is that defined in arm/cpus.yaml? No.
>
> The current choices are perf or psci though those aren't enforced (yet).
> Or nothing which is my preference if there is only 1 power domain.

Right. It's not really clear in arm/cpus.yaml what name to use for a
perf domain, except for "perf" for SCMI.

If we want to move towards some alignment, perhaps we should update
the DT doc to make "perf" the common suggestion? I can send a patch if
you think it makes sense?

Even if there is only 1 power-domain at this point, we never know if
another one turns up later, for whatever reasons. That said, isn't it
better to be specific about a name, already at this point?

Kind regards
Uffe