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: <2lpx7rsko24e45gexsv3jp4ntwwenag47vgproqljqeuk4j7iy@zgh6hrln4h4e>
Date: Mon, 5 Jan 2026 10:44:39 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, Taniya Das <quic_tdas@...cinc.com>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Bartosz Golaszewski <brgl@...nel.org>,
        Shazad Hussain <quic_shazhuss@...cinc.com>,
        Sibi Sankar <sibi.sankar@....qualcomm.com>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Melody Olvera <quic_molvera@...cinc.com>,
        Dmitry Baryshkov <lumag@...nel.org>,
        Taniya Das <taniya.das@....qualcomm.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Imran Shaik <quic_imrashai@...cinc.com>,
        Abel Vesa <abelvesa@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rajendra Nayak <quic_rjendra@...cinc.com>, stable@...r.kernel.org
Subject: Re: [PATCH 0/7] clk: qcom: gcc: Do not turn off PCIe GDSCs during
 gdsc_disable()

On Fri, Jan 02, 2026 at 02:57:56PM +0100, Konrad Dybcio wrote:
> On 1/2/26 2:19 PM, Krishna Chaitanya Chundru wrote:
> > 
> > 
> > On 1/2/2026 5:09 PM, Konrad Dybcio wrote:
> >> On 1/2/26 12:36 PM, Krishna Chaitanya Chundru wrote:
> >>>
> >>> On 1/2/2026 5:04 PM, Konrad Dybcio wrote:
> >>>> On 1/2/26 10:43 AM, Krishna Chaitanya Chundru wrote:
> >>>>> With PWRSTS_OFF_ON, PCIe GDSCs are turned off during gdsc_disable(). This
> >>>>> can happen during scenarios such as system suspend and breaks the resume
> >>>>> of PCIe controllers from suspend.
> >>>> Isn't turning the GDSCs off what we want though? At least during system
> >>>> suspend?
> >>> If we are keeping link in D3cold it makes sense, but currently we are not keeping in D3cold
> >>> so we don't expect them to get off.
> >> Since we seem to be tackling that in parallel, it seems to make sense
> >> that adding a mechanism to let the PCIe driver select "on" vs "ret" vs
> >> "off" could be useful for us
> > At least I am not aware of such API where we can tell genpd not to turn off gdsc
> > at runtime if we are keeping the device in D3cold state.
> > But anyway the PCIe gdsc supports Retention, in that case adding this flag here makes
> > more sense as it represents HW.
> > sm8450,sm8650 also had similar problem which are fixed by mani[1].
> 
> Perhaps I should ask for a clarification - is retention superior to
> powering the GDSC off? Does it have any power costs?
> 

In terms of power saving it is not superior, but that's not the only factor we
should consider here. If we keep GDSCs PWRSTS_OFF_ON, then the devices (PCIe)
need to be be in D3Cold. Sure we can change that using the new genpd API
dev_pm_genpd_rpm_always_on() dynamically, but I would prefer to avoid doing
that.

In my POV, GDSCs default state should be retention, so that the GDSCs will stay
ON if the rentention is not entered in hw and enter retention otherwise. This
requires no extra modification in the genpd client drivers. One more benefit is,
the hw can enter low power state even when the device is not in D3Cold state
i.e., during s2idle (provided we unvote other resources).

If the hw doesn't support retention like Makena PCIe GDSC, then PWRSTS_OFF_ON is
the only option.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ