linux-kernel - Re: [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp

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: <qg4dof65dyggzgvkroeo2suhhnvosqs3dnkrmsqpbf4z67dcht@ltzirahk2mxd>
Date: Wed, 16 Jul 2025 12:16:42 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
Cc: 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, Johan Hovold <johan@...nel.org>
Subject: Re: [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp_update() to
 notifier callback

On Wed, Jul 16, 2025 at 10:24:23AM GMT, Krishna Chaitanya Chundru wrote:
> 
> 
> On 7/15/2025 4:06 PM, Manivannan Sadhasivam wrote:
> > On Tue, Jul 15, 2025 at 11:54:48AM GMT, Konrad Dybcio wrote:
> > > On 7/14/25 8:01 PM, Manivannan Sadhasivam wrote:
> > > > It allows us to group all the settings that need to be done when a PCI
> > > > device is attached to the bus in a single place.
> > > > 
> > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
> > > > ---
> > > >   drivers/pci/controller/dwc/pcie-qcom.c | 3 +--
> > > >   1 file changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > > index b4993642ed90915299e825e47d282b8175a78346..b364977d78a2c659f65f0f12ce4274601d20eaa6 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > > > @@ -1616,8 +1616,6 @@ static irqreturn_t qcom_pcie_global_irq_thread(int irq, void *data)
> > > >   		pci_lock_rescan_remove();
> > > >   		pci_rescan_bus(pp->bridge->bus);
> > > >   		pci_unlock_rescan_remove();
> > > > -
> > > > -		qcom_pcie_icc_opp_update(pcie);
> > > >   	} else {
> > > >   		dev_WARN_ONCE(dev, 1, "Received unknown event. INT_STATUS: 0x%08x\n",
> > > >   			      status);
> > > > @@ -1765,6 +1763,7 @@ static int pcie_qcom_notify(struct notifier_block *nb, unsigned long action,
> > > >   	switch (action) {
> > > >   	case BUS_NOTIFY_BIND_DRIVER:
> > > >   		qcom_pcie_enable_aspm(pdev);
> > > > +		qcom_pcie_icc_opp_update(pcie);
> > > 
> > > So I assume that we're not exactly going to do much with the device if
> > > there isn't a driver for it, but I have concerns that since the link
> > > would already be established(?), the icc vote may be too low, especially
> > > if the user uses something funky like UIO
> > > 
> > 
> > Hmm, that's a good point. Not enabling ASPM wouldn't have much consequence, but
> > not updating OPP would be.
> > 
> > Let me think of other ways to call these two APIs during the device addition. If
> > there are no sane ways, I'll drop *this* patch.
> > 
> 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.

- Mani

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