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: <f431ab4e-fdd3-4771-a770-558cdba9ef75@linaro.org>
Date: Sat, 30 Dec 2023 15:10:29 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Johan Hovold <johan+linaro@...nel.org>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Konrad Dybcio <konrad.dybcio@...ainline.org>
Subject: Re: [PATCH 3/3] arm64: dts: qcom: sc8280xp-crd: Add PCIe CLKREQ#
 sleep state

On 29.12.2023 18:14, Manivannan Sadhasivam wrote:
> On Wed, Dec 27, 2023 at 11:28:28PM +0100, Konrad Dybcio wrote:
>> The CLKREQ pin should not be muxed to its active function when the RC
>> is asleep. Add the missing pin sleep states to resolve that.
>>
> 
> I don't understand why it should not be muxed and wondering what is the actual
> issue you are seeing that lead to this conclusion.

According to my knowledge, demuxing this pin prevents the RC from
getting (possibly erronous) reference clock request signals when
running the RC shutdown sequence. Reading this again, the fixes
tags don't really fit this commit.

What's perhaps more interesting is that on msm8996, Qualcomm vendor
kernels used to remove the pull-up on the CLKREQ pin in its sleep
state, while on msm8998 through sm8550 they keep it there, always..
Perhaps an oversight?

Konrad


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ