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: <6124f9e9-3fdf-29b1-128f-c58f5ebe1424@quicinc.com>
Date: Mon, 15 Jul 2024 16:06:59 +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/11/2024 3:21 PM, Bryan O'Donoghue wrote:
> On 10/07/2024 23:10, Dmitry Baryshkov wrote:
>>>> - Why is cam_cc_gdsc_clk not modelled in the clock framework?
>>>
>>> This clock is kept enabled from probe, hence not required to be 
>>> modelled
>>> explicitly.
>> Yes, I'm asking why it's kept up enabled from probe rather than via
>> clock framework?
>
> FWIW my preference is to do it as Dmitry is suggesting here.
>
> I'm not a big fan of hitting the register and leaving it as-is, would 
> much prefer to move to the model of having the CCF do it - so that for 
> example the clock appears in the /sys clock summary.
>

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.


> ---
> bod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ