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: <32bcb19f-db74-8660-7270-305e81363376@kernel.org>
Date:   Tue, 21 Mar 2023 15:56:40 +0200
From:   Georgi Djakov <djakov@...nel.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface clocks

Hi Konrad,

Thank you for working on this and sorry about jumping a bit late into
the discussion.

On 8.03.23 23:40, Konrad Dybcio wrote:
> Some (but not all) providers (or their specific nodes) require
> specific clocks to be turned on before they can be accessed. Failure
> to ensure that results in a seemingly random system crash (which
> would usually happen at boot with the interconnect driver built-in),
> resulting in the platform not booting up properly.

These "interface" clocks seem to be used only to program QoS for the
respective ip block (eg ufs). So if we don't program QoS, there should
be no crashes, right?

I believe that in downstream they defer setting QoS until the first
non-zero bandwidth request because of drivers that probe asynchronously
or there is some firmware booting involved (IPA maybe). And bad stuff
might happen if we touch the clock while the firmware is still booting.
So setting the QoS on the first non-zero bandwidth request might not be
a bad idea. Such nodes should probably be also excluded from sync_state
by implementing get_bw() to return 0 bandwidth.

BR,
Georgi

> 
> Limit the number of bus_clocks to 2 (which is the maximum that SMD
> RPM interconnect supports anyway) and handle non-scaling clocks
> separately. Update MSM8996 and SDM660 drivers to make sure they do
> not regress with this change.
> 
> This unfortunately has to be done in one patch to prevent either
> compile errors or broken bisect.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> ---
>   drivers/interconnect/qcom/icc-rpm.c | 52 ++++++++++++++++++++++++++++++-------
>   drivers/interconnect/qcom/icc-rpm.h | 14 ++++++++--
>   drivers/interconnect/qcom/msm8996.c | 22 +++++++---------
>   drivers/interconnect/qcom/sdm660.c  | 16 +++++-------
>   4 files changed, 70 insertions(+), 34 deletions(-)
> 
[..]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ