linux-kernel - Re: [PATCH v2 5/5] PCI/pwrctrl: Switch to the new pwrctrl APIs

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] [day] [month] [year] [list]

Message-ID: <myrl5u2zhcoofzub6xy7wmw37h66ut4uxeiirvnbvxrikud6r2@zxgzzd454ciq>
Date: Sat, 27 Dec 2025 10:14:12 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Sean Anderson <sean.anderson@...o.com>, 
	Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>, Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Krzysztof Wilczyński <kwilczynski@...nel.org>, Rob Herring <robh@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Bartosz Golaszewski <brgl@...ev.pl>, 
	Bartosz Golaszewski <brgl@...nel.org>, linux-pci@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Chen-Yu Tsai <wens@...nel.org>, 
	Brian Norris <briannorris@...omium.org>, Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>, 
	Niklas Cassel <cassel@...nel.org>, Alex Elder <elder@...cstar.com>, 
	Chen-Yu Tsai <wenst@...omium.org>
Subject: Re: [PATCH v2 5/5] PCI/pwrctrl: Switch to the new pwrctrl APIs

On Fri, Dec 26, 2025 at 05:07:11PM -0600, Bjorn Helgaas wrote:
> On Tue, Dec 23, 2025 at 07:41:30PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Dec 19, 2025 at 01:35:39PM -0500, Sean Anderson wrote:
> > > On 12/16/25 07:51, Manivannan Sadhasivam wrote:
> > > > Adopt the recently introduced pwrctrl APIs to create, power on, destroy,
> > > > and power off pwrctrl devices. In qcom_pcie_host_init(), call
> > > > pci_pwrctrl_create_devices() to create devices, then
> > > > pci_pwrctrl_power_on_devices() to power them on, both after controller
> > > > resource initialization. Once successful, deassert PERST# for all devices.
> 
> > ...
> > > And now you will continually probe the controller until all of the
> > > drivers are loaded.
> > > 
> > > There is a non-obvious property of the deferred probe infrastructure
> > > which is:
> > > 
> > >         Once a device creates children, it must never fail with
> > >         EPROBE_DEFER.
> > > 
> > > So if you want to have something like this, the pwrctrl devices need to
> > > be created before the controller is probed. Or you can use the current
> > > system where the pwrctrl devices are probed asynchronously.
> > 
> > You are right and it is an oversight from me. If the pwrctrl driver
> > is not found, the pwrctrl devices should not be destroyed in the
> > error path, but the controller driver can still return
> > -EPROBE_DEFER. This will allow the controller driver to get reprobed
> > later and by that time, pwrctrl device creation will be skipped. I
> > believe this satisfies the comment you quoted above.
> > 
> > I found this issue while testing the series with one of our Qcom
> > switches and I fixed it in yet to be submitted v3.
> 
> I guess I should wait for v3 before putting this in linux-next?

Yes, please. I'll send v4 today or tomorrow.

- Mani

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