linux-kernel - Re: [PATCH v2 3/3] PCI: qcom: properly implement RC shutdown/power up

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: <27560098-ced3-4672-bc60-6c1b7c0dc807@linaro.org>
Date: Wed, 14 Feb 2024 22:33:19 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Krzysztof Wilczyński <kw@...ux.com>,
 Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, linux-arm-msm@...r.kernel.org,
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
 Johan Hovold <johan+linaro@...nel.org>,
 Bjorn Andersson <quic_bjorande@...cinc.com>
Subject: Re: [PATCH v2 3/3] PCI: qcom: properly implement RC shutdown/power up

On 12.02.2024 22:32, Bjorn Helgaas wrote:
> "Properly" is a noise word that suggests "we're doing it right this
> time" but doesn't hint at what actually makes this better.
> 
> On Sat, Feb 10, 2024 at 06:10:07PM +0100, Konrad Dybcio wrote:
>> Currently, we've only been minimizing the power draw while keeping the
>> RC up at all times. This is suboptimal, as it draws a whole lot of power
>> and prevents the SoC from power collapsing.
> 
> Is "power collapse" a technical term specific to this device, or is
> there some more common term that could be used?  I assume the fact
> that the RC remains powered precludes some lower power state of the
> entire SoC?

That's spot on, "power collapse" commonly refers to shutting down as many
parts of the SoC as possible, in order to achieve miliwatt-order power draw.


> 
>> Implement full shutdown and re-initialization to allow for powering off
>> the controller.
>>
>> This is mainly indended for SC8280XP with a broken power rail setup,
>> which requires a full RC shutdown/reinit in order to reach SoC-wide
>> power collapse, but sleeping is generally better than not sleeping and
>> less destructive suspend can be implemented later for platforms that
>> support it.
> 
> s/indended/intended/
> 
>>  config PCIE_QCOM
>>  	bool "Qualcomm PCIe controller (host mode)"
>>  	depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> +	depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
> 
> Just out of curiosity since I'm not a Kconfig expert, what does
> "depends on X || X=n" mean?  

"not a module"

> 
> I guess it's different from
> "depends on (QCOM_COMMAND_DB || !QCOM_COMMAND_DB)", which I also see
> used for QCOM_RPMH?

Yep

> 
> Does this reduce compile testing?  I see COMPILE_TEST mentioned in a
> few other QCOM_COMMAND_DB dependencies.

I can add "&& COMPILE_TEST", yeah

> 
>> +	ret_l23 = readl_poll_timeout(pcie->parf + PARF_PM_STTS, val,
>> +				     val & PM_ENTER_L23, 10000, 100000);
> 
> Are these timeout values rooted in some PCIe or Qcom spec?  Would be
> nice to have a spec citation or other reason for choosing these
> values.
> 
>> +	reset_control_assert(res->rst);
>> +	usleep_range(2000, 2500);
> 
> Ditto, some kind of citation would be nice.

Both are magic values coming from Qualcomm BSP, that we suppose
we can safely assume (and that's a two-level assumption at this
point, I know..) is going to work fine, as it does so on millions
of shipped devices.

Maybe Mani or Bjorn A can find something interesting in the documentation.

Konrad