linux-kernel - Re: [PATCH] clk: qcom: gcc-msm8994: Remove NoC clocks

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]

Message-ID: <e6ac0b79-368b-41af-f20d-f58ddc02f05e@somainline.org>
Date:   Thu, 30 Dec 2021 15:26:48 +0100
From:   Konrad Dybcio <konrad.dybcio@...ainline.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     ~postmarketos/upstreaming@...ts.sr.ht, martin.botka@...ainline.org,
        angelogioacchino.delregno@...ainline.org,
        marijn.suijten@...ainline.org, jamipkettunen@...ainline.org,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clk: qcom: gcc-msm8994: Remove NoC clocks


On 30.12.2021 15:06, Dmitry Baryshkov wrote:
> On Thu, 30 Dec 2021 at 05:31, Konrad Dybcio
> <konrad.dybcio@...ainline.org> wrote:
>> Just like in commit 05cf3ec00d460b50088d421fb878a0f83f57e262
>> ("clk: qcom: gcc-msm8996: Drop (again) gcc_aggre1_pnoc_ahb_clk")
>> adding NoC clocks turned out to be a huge mistake, as they cause a lot of
>> issues at little benefit (basically only letting Linux know about their
>> children's frequencies), especially when mishandled or misconfigured.
> I'm not against this patch, but it manifests another question to me:
> should the NoC driver set these frequencies (as demanded), or are they
> set by the hardware/RPM/etc and so are read-only to us?

The downstream driver [1] only seems to vote for 19.2 MHz on

p(c)noc_keepalive_a_clk and 40MHz on mmssnoc_ahb_a_clk and

not really care much about them otherwise in the (msm_)clk framework.


Interestingly, the voting-at-probe also seems to be true for 8916 [2],

and even more so for 8974 [3] which votes for CXO too, and I don't

think we handle it upstream.. Is it unnecessary, or did things always

work by miracle? Should we perhaps set it with assigned-clocks under

rpmcc in DT?


Otherwise, they seem to be handled by msm_bus's voter clocks, so in

our case that'll be interconnect's job. I had an old WIP driver somewhere,

but it had issues with some (well, many) paths.. I'll rebase it and try debugging

that.


Decoding ancient msm-3.10 code is not for the faint of heart, but I don't think

8994 or 8974 (which are similar in many ways) ever got a newer kernel release..


[..]


Konrad


[1] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/clk/qcom/clock-rpm-8994.c#L292


[2] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/clk/qcom/clock-rpm-8916.c#L168


[3] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/arch/arm/mach-msm/clock-rpm-8974.c