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] [day] [month] [year] [list]

Message-ID: <ZBNRukXEliI2auDa@google.com>
Date:   Thu, 16 Mar 2023 17:28:26 +0000
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Nikita Travkin <nikita@...n.ru>
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

On Thu, Mar 16, 2023 at 08:42:03AM +0500, Nikita Travkin wrote:
> 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 the clarification!