linux-kernel - Re: [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 5 May 2021 12:41:18 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Sibi Sankar <sibis@...eaurora.org>
Cc:     bjorn.andersson@...aro.org, viresh.kumar@...aro.org,
        Sudeep Holla <sudeep.holla@....com>, swboyd@...omium.org,
        agross@...nel.org, robh+dt@...nel.org, rjw@...ysocki.net,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        dianders@...omium.org, mka@...omium.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables

On Wed, May 05, 2021 at 03:39:17PM +0530, Sibi Sankar wrote:
> On 2021-05-05 14:19, Sudeep Holla wrote:

[...]

> > But I am not sure how this is related to the above commit anyways.
> >
> > >
> > > I guess your main concern for breakage is ^^ commit? The original
> > > design is
> > > to list a super set of frequencies supported by all variants of the
> > > SoC
> > > along with the required DDR/L3 bandwidth values. When we run into
> > > non-documented frequency we just wouldn't put in bw votes for it which
> > > should be fine since the entire opp_table is optional. If this is
> > > the reason
> > > for the NACK I can try get it reverted with Matthias's ack.
> >
> > No my main concern is this platform uses "qcom-cpufreq-hw" driver and
> > the
> > fact that the OPPs are retrieved from the hardware lookup table
> > invalidates
> > whatever we have in DT. In short it will be junk and becomes obsolete.
>
> The table provides mapping to bandwidths which aren't available in the
> firmware though. In short we do have to store the mapping somewhere i.e. a
> mapping that lists all possible frequencies to its bandwidth requirements
> needs to be present and using a opp table with the interconnect bw bindings
> was the consensus reached.

I understand and that's exactly what I had pointed out earlier when I
mentioned that I had raised this concern previously.

> Given that a duplicate mapping that lists all possible frequencies to bw is
> inevitable

I disagree, it was made inevitable by not listening to all feedback, sorry.

> and Qualcomm has a way of listing all the supported frequencies for the SoC,
> I feel that dt breakage in the future should be a non-concern.

I don't completely understand this TBH. Also my main worry is as we move more
towards abstract scale and/or index based, any addition or deletion of OPPs
results in change in the index or scale. It may be dealt on absolute scale
today everywhere and not a problem *today*, but it will break IMO.

> Not sure why you call it junk since it solves the perf/power requirements on
> SDM845/SC7180 SoCs. When it becomes obsolete it would mean that they are
> better devfreq governors available upstream and that's a good reason for the
> opp tables to go away.
>

Nope, I meant the firmware updates the OPP table underneath for whatever
valid reasons it may have.

> > So what I suggested before is still valid. You simply can't have static
> > OPP tables in the DT for this platform. Do get some boot code to fetch
> > the same from the h/w LUT and patch to the DT or figure out any other way
> > to manage dynamically.
>
> moving the logic to boot loader doesn't magically fix your concerns though
> (since it would also need a superset of available frequencies).


OK that's interesting. I wanted to fetch the exact list from the hardware
every time.

> It will suffer from the same problems with an additional dependency on
> firmware propagation in case of breakages which is something you can avoid
> for the simple cpu based scaling solution.

IMO the cross dependency is one part of problem and fetching the exact list
of OPPs available for the CPU is another. I meant to fix the latter in boot
code. The former is something I assume DT bindings deals with.

> >
> > So NACK still stands for static addition of OPPs to the DT as in this
> > patch.
>
> I'll let Viresh take the call since this solution is already used on older SoCs.

Sure, definitely I am just expressing my concern with NACK and I don't have
the final say 😁.

--
Regards,
Sudeep