linux-kernel - Re: [PATCH v2 5/6] clk: qcom: Add camera clock controller driver for SM8150

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: <b6aefcee-808c-77cd-7632-52ab21a14a54@quicinc.com>
Date: Wed, 17 Jul 2024 16:38:43 +0530
From: "Satya Priya Kakitapalli (Temp)" <quic_skakitap@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio
	<konrad.dybcio@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, Abhishek Sahu <absahu@...eaurora.org>,
        "Rob
 Herring" <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Stephen Boyd <sboyd@...eaurora.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-clk@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, Ajit Pandey <quic_ajipan@...cinc.com>,
        "Imran
 Shaik" <quic_imrashai@...cinc.com>,
        Taniya Das <quic_tdas@...cinc.com>,
        Jagadeesh Kona <quic_jkona@...cinc.com>
Subject: Re: [PATCH v2 5/6] clk: qcom: Add camera clock controller driver for
 SM8150


On 7/17/2024 4:23 PM, Bryan O'Donoghue wrote:
> On 15/07/2024 11:36, Satya Priya Kakitapalli (Temp) wrote:
>> This clock is PoR ON clock and expected to be always enabled from HW 
>> perspective, we are just re-ensuring it is ON from probe. Modelling 
>> this clock is unnecessary, and we have been following this approach 
>> for  gdsc clock in all the recent chipsets, like for example sm8550 
>> camcc.
>
> Having a difficult time following the logic
>
> - Re-enabling an already enabled always-on clock is necessary


There is no hard requirement to enable it again , but to be on safe side 
incase bootloaders disabled this clock, we are enabling it again in probe.


> - Modelling the always-on clock in the CCF to park it at XO is
>   unnecessary
>

Modelling the clock will cause the CCF to disable the clock in late 
init. I have tested on SM8150 by modelling the gdsc clock now and I see 
it is getting disabled in late init.


Parking the parent clock(rcg) at XO, doesn't ensure the branch clock to 
be ON. If CCF disables the clock it gets disabled.


> I think that's a pretty vague argument to be honest.
>
> ---
> bod