linux-kernel - Re: [PATCH V2 RESEND 6/6] arm64: dts: qcom: sm8650: Add video and camera clock controllers

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: Thu, 18 Apr 2024 23:56:09 +0300
From: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
 Jagadeesh Kona <quic_jkona@...cinc.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Taniya Das <quic_tdas@...cinc.com>,
 Satya Priya Kakitapalli <quic_skakitap@...cinc.com>,
 Ajit Pandey <quic_ajipan@...cinc.com>,
 Imran Shaik <quic_imrashai@...cinc.com>
Subject: Re: [PATCH V2 RESEND 6/6] arm64: dts: qcom: sm8650: Add video and
 camera clock controllers

Hi Konrad,

On 3/23/24 02:33, Konrad Dybcio wrote:
> On 21.03.2024 14:07, Vladimir Zapolskiy wrote:
>> Hello Jagadeesh,
>>
>> On 3/21/24 11:25, Jagadeesh Kona wrote:
>>> Add device nodes for video and camera clock controllers on Qualcomm
>>> SM8650 platform.
>>>
>>> Signed-off-by: Jagadeesh Kona <quic_jkona@...cinc.com>
>>> ---
>>>    arch/arm64/boot/dts/qcom/sm8650.dtsi | 28 ++++++++++++++++++++++++++++
>>>    1 file changed, 28 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> index 32c0a7b9aded..d862aa6be824 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> @@ -4,6 +4,8 @@
>>>     */
>>>      #include <dt-bindings/clock/qcom,rpmh.h>
>>> +#include <dt-bindings/clock/qcom,sm8450-videocc.h>
>>> +#include <dt-bindings/clock/qcom,sm8650-camcc.h>
>>>    #include <dt-bindings/clock/qcom,sm8650-dispcc.h>
>>>    #include <dt-bindings/clock/qcom,sm8650-gcc.h>
>>>    #include <dt-bindings/clock/qcom,sm8650-gpucc.h>
>>> @@ -3110,6 +3112,32 @@ opp-202000000 {
>>>                };
>>>            };
>>>    +        videocc: clock-controller@...0000 {
>>> +            compatible = "qcom,sm8650-videocc";
>>> +            reg = <0 0x0aaf0000 0 0x10000>;
>>> +            clocks = <&bi_tcxo_div2>,
>>> +                 <&gcc GCC_VIDEO_AHB_CLK>;
>>> +            power-domains = <&rpmhpd RPMHPD_MMCX>;
>>> +            required-opps = <&rpmhpd_opp_low_svs>;
>>
>> Please add default status = "disabled";
>>
>>> +            #clock-cells = <1>;
>>> +            #reset-cells = <1>;
>>> +            #power-domain-cells = <1>;
>>> +        };
>>> +
>>> +        camcc: clock-controller@...0000 {
>>> +            compatible = "qcom,sm8650-camcc";
>>> +            reg = <0 0x0ade0000 0 0x20000>;
>>> +            clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>>> +                 <&bi_tcxo_div2>,
>>> +                 <&bi_tcxo_ao_div2>,
>>> +                 <&sleep_clk>;
>>> +            power-domains = <&rpmhpd RPMHPD_MMCX>;
>>> +            required-opps = <&rpmhpd_opp_low_svs>;
>>
>> Please add default status = "disabled";
>>
>>> +            #clock-cells = <1>;
>>> +            #reset-cells = <1>;
>>> +            #power-domain-cells = <1>;
>>> +        };
>>> +
>>>            mdss: display-subsystem@...0000 {
>>>                compatible = "qcom,sm8650-mdss";
>>>                reg = <0 0x0ae00000 0 0x1000>;
>>
>> After disabling the clock controllers
> 
> Clock controllers should never be disabled period, that defeats the
> entire point of having unused clk/pd cleanup.

hm, that's very sane, I didn't think about it from this point, thanks!

> The only reason for them to be disabled is for cases where platform
> crashes on access due to stinky "security" settings (like with audio
> clocks), or when people are too lazy to upstream panel drivers and
> end up partially upstreaming display-related changes and continue
> using the bootloader-initialized framebuffer. This takes away from
> the very little determinism we have.
> 

--
Best wishes,
Vladimir