linux-kernel - Re: [PATCH v3 1/4] arm64: dts: qcom: sc7180: Don't enable lpass clocks by default

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: <67077784fcf9aa928be9a6503e3d1e83@trvn.ru>
Date:   Thu, 16 Mar 2023 08:42:03 +0500
From:   Nikita Travkin <nikita@...n.ru>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     agross@...nel.org, andersson@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, konrad.dybcio@...aro.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v3 1/4] arm64: dts: qcom: sc7180: Don't enable lpass
 clocks by default

Matthias Kaehlcke писал(а) 16.03.2023 05:28:
> On Wed, Mar 15, 2023 at 08:43:08PM +0500, Nikita Travkin wrote:
>> lpass clocks are usually blocked from HLOS by the firmware and
>> instead are managed by the ADSP. Mark them as reserved and explicitly
>> enable in the CrOS boards that have special, cooperative firmware.
>>
>> Signed-off-by: Nikita Travkin <nikita@...n.ru>
>> ---
>>  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8 ++++++++
>>  arch/arm64/boot/dts/qcom/sc7180.dtsi         | 4 ++++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>> index 423630c4d02c..26def6e12723 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>> @@ -785,6 +785,14 @@ alc5682: codec@1a {
>>  	};
>>  };
>>
>> +&lpasscc {
>> +	status = "okay";
>> +};
>> +
>> +&lpass_hm {
>> +	status = "okay";
>> +};
>> +
>>  &lpass_cpu {
>>  	status = "okay";
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
>> index 53f0076f20f6..f0de177981f9 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
>> @@ -3623,6 +3623,8 @@ lpasscc: clock-controller@...00000 {
>>  			power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>;
>>  			#clock-cells = <1>;
>>  			#power-domain-cells = <1>;
>> +
>> +			status = "reserved"; /* Controlled by ADSP */
> 
> Why not "disabled"? I see "reserved" is used in a couple of other
> instances, but it doesn't appear in Documentation/devicetree/bindings/,
> so it doesn't seem to have a well defined meaning that distinguishes it
> from "disabled".

Hi, the standard properties like this one are defined in the
Devicetree specification, notably chapter 2.3.4 "status" says:

  "reserved" Indicates that the device is operational, but should
  not be used. Typically this is used for devices that are controlled
  by another software component, such as platform firmware.

On the contrary,

  "disabled" Indicates that the device is not presently operational (...)

Since the hardware is operational but is controlled by "foreign"
firmware, I believe "reserved" state is more correct here.

Thanks for looking at the patch!
Nikita

> 
>>  		};
>>
>>  		lpass_cpu: lpass@...87000 {
>> @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@...00000 {
>>
>>  			#clock-cells = <1>;
>>  			#power-domain-cells = <1>;
>> +
>> +			status = "reserved"; /* Controlled by ADSP */
>>  		};
>>  	};
>>
>> --
>> 2.39.2
>>