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: <0af8ba67-f33c-4861-bea5-e662d19638bf@kernel.org>
Date:   Tue, 21 Mar 2023 15:58:30 +0200
From:   Georgi Djakov <djakov@...nel.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.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,

On 11.03.23 17:26, Dmitry Baryshkov wrote:
> On 11/03/2023 16:38, Bryan O'Donoghue wrote:
>> On 11/03/2023 14:35, Dmitry Baryshkov wrote:
>>>> Its probably worthwhile experimenting to see if the*ufs*_clk can/should
>>>> be added to the UFS device list of clocks.
>>> While we were doing this for some of the clocks (PCIe and USB, if I'm
>>> not mistaken), I think that generally this is not fully correct. In my
>>> opinion it should be in the interconnect driver, who turns
>>> corresponding clocks on and off. These clocks correspond to the SoC
>>> topology, rather than the end-device.
>>>
>>
>> True enough, they are interconnect clocks.
>>
>> The question is how to only turn them on when the device that depends on them wants them.
> 
> I think we can turn them on an off from qcom_icc_set(). Each node can list required clocks.
> 

Yes, this is a bit weird, but looks like these are the interface clocks
required for programming the qos box of the respective peripheral and
nothing else. Maybe we can even configure QoS just once (eg. on the first
bandwidth request) and not every time we call qcom_icc_set().

BR,
Georgi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ