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

[Bjorn Helgaas <helgaas@kernel.org>]

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?