linux-kernel - Re: [RFC] clk: qcom: common: Detach the power domain at the end of probe

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: <20220804165609.hbrcylpayu4ypsbt@linaro.org>
Date:   Thu, 4 Aug 2022 19:56:09 +0300
From:   Abel Vesa <abel.vesa@...aro.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Rajendra Nayak <quic_rjendra@...cinc.com>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Mike Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] clk: qcom: common: Detach the power domain at the end of
 probe

On 22-08-04 17:37:48, Dmitry Baryshkov wrote:
> On Thu, 4 Aug 2022 at 13:35, Abel Vesa <abel.vesa@...aro.org> wrote:
> >
> > None of the CCs actually need the PD attached to their device,
> > but rather some GDSCs registered by those CCs need that PD as a parent
> > in order to propagate power gating and the performance state.
> >
> > So lets detach the PD from the CC right at the end of probe, after
> > everything has been successfully set up.
>
> Would it still be possible to read the clock registers if we detach
> the device from the domain?
> I think it was the original issue behind putting the dispcc/videocc
> into the MMCX domain: to be able to poke into the clock registers,
> which are gated by the MMCX.

+Rajendra

OK, so I might be wrong here, so I'll need to double check. But, AFAICT,
today, most of the CCs devicetree nodes do not have a power-domain property.
So I assuming the PD is never really needed for register access by the CC
itself, but its only use is to be set as parent to those GDSCs that do
not have specified a different parent.

Again, I need to double check.

>
>
> > Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
>
>
> --
> With best wishes
> Dmitry