On Fri, Oct 11, 2024 at 04:14:10PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 10/11/2024 2:22 AM, Bjorn Helgaas wrote:
> > On Thu, Oct 10, 2024 at 01:29:50PM -0700, Mayank Rana wrote:
> > > Commit 02787a3b4d10 ("PCI/PM: Enable runtime power management for host
> > > bridges") enables runtime PM for host bridge enforcing dependency chain
> > > between PCIe controller, host bridge and endpoint devices. With this,
> > > Starfive PCIe controller driver's probe enables host bridge (child device)
> > > PM runtime before parent's PM runtime (Starfive PCIe controller device)
> > > causing below warning and callstack:
> >
> > I don't want the bisection hole that would result if we kept
> > 02787a3b4d10 ("PCI/PM: Enable runtime power management for host
> > bridges") and applied this patch on top of it.
> >
> > If this is the fix, we'll apply it *first*, followed by 02787a3b4d10
> > (which will obviously become a different commit), so the locking
> > problem below described below should never exist in -next or the
> > upstream tree.
> >
> > So we need to audit other drivers to make sure they don't have theBjorn, I have checked all the drivers in the controller folder where
> they are using pm_runtime_enable(), this is the only driver which needs
> to be fixed. once this patched was taken can we take "PCI/PM: Enable
> runtime power management for host bridges"
Since these need to be applied in order, the usual process is to post
them together in one series. Please work with Mayank to revise the
commit log of the starfive patch so it explains why the change is
necessary *independent* of your patch, and then post it and your
"enable runtime PM for host bridges" together as v6 of your patch.
In the cover letter include a note about why no other drivers need a
change like starfive does and how we can verify that.
Bjorn
