[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ekg5lpnqeer5j3vka3rhfh5sf6sid4gnr5bzyxysjqfftxrjcy@bitmxfnhbe5f>
Date: Mon, 21 Jul 2025 16:29:01 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
Konrad Dybcio <konrad.dybcio@....qualcomm.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>,
linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp_update() to
notifier callback
On Mon, Jul 21, 2025 at 11:02:01AM GMT, Johan Hovold wrote:
> On Wed, Jul 16, 2025 at 12:16:42PM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Jul 16, 2025 at 10:24:23AM GMT, Krishna Chaitanya Chundru wrote:
>
> > > How about using enable_device in host bridge, without pci_enable_device
> > > call the endpoints can't start the transfers. May be we can use that.
> >
> > Q: Who is going to call pci_enable_device()?
> > A: The PCI client driver
> >
> > This is same as relying on BUS_NOTIFY_BIND_DRIVER notifier.
>
> It seems to me that enable_device() may be a better fit if we're only
> going to enable ASPM for devices with a driver (or when enabled through
> sysfs).
>
> PCI core will already have placed the device in D0, and this avoids
> dealing with notifiers.
>
I'm planning to drop this series in favor of this patch (with one
yet-to-be-submitted patch for pcie-qcom on top):
https://lore.kernel.org/linux-pci/20250720190140.2639200-1-david.e.box@linux.intel.com/
This patch is more elegant compared to this series and also avoids the issue
we are discussing.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists