linux-kernel - Re: [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface 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: <67590cd3-5543-59ed-6158-b272103ebd05@linaro.org>
Date:   Fri, 10 Mar 2023 16:47:46 +0000
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Georgi Djakov <djakov@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface clocks

On 10/03/2023 14:26, Konrad Dybcio wrote:
> 
> 
> On 10.03.2023 15:21, Bryan O'Donoghue wrote:
>> On 08/03/2023 21:40, Konrad Dybcio wrote:
>>> Some (but not all) providers (or their specific nodes) require
>>> specific clocks to be turned on before they can be accessed. Failure
>>> to ensure that results in a seemingly random system crash (which
>>> would usually happen at boot with the interconnect driver built-in),
>>> resulting in the platform not booting up properly.
>>
>> Can you give an example of which clocks on which SoC's ?
> See for example 67fb53745e0b
> 
> This was a clock documented downstream under the node-qos clocks here:
> 
> https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.5.7.r1/arch/arm/boot/dts/qcom/msm8996-bus.dtsi#L102-L109
> 
> but there are occasions where such clocks are undocumented and downstream
> skips them because it relies on them being on by miracle, such as the case
> of MASTER_IPA and the IPA rpmcc clock on msm8998. Downstream has no
> sync_state, so they would only set the QoS registers when the relevant
> hardware was online, so the clocks were on already.

What switched the clocks on ? Presumably LK.

Is this a symptom of using a bootloader other than LK ? If you use the 
same bootloader, then why hasn't the bootloader/LK already set it up on 
your platform ?

>>
>> Is the intention of this patch to subsequently go through *.dts *.dtsi and start to remove assigned-clocks ?
>>
>> Are we saying that currently there ought to be assigned-clocks for some of these NoC declarations ?
> Not really, assigned-clocks are used for static ratesetting, see
> for example dwc3 nodes where we need it to be fast enough for
> HS/SS operation at all times (though that should have prooobably
> been handled in the driver but it's a separate topic), I don't
> think any of them were used to combat what this commit tries to.

I think you could use assigned-clocks for that ..

So its not part of your series but then presumably you have a follow-on 
patch for the 8998 dts that points your ->intf_clks at these then ?

clocks = <&clock_gcc clk_aggre2_noc_clk>,
          <&clock_gcc clk_gcc_ufs_axi_clk>,
          <&clock_gcc clk_gcc_aggre2_ufs_axi_clk>;

It seems like the right thing to do..

Still not clear why these clocks are off.. your bootchain ?

---
bod