All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-kernel@vger.kernel.org, Lukas Wunner <lukas@wunner.de>,
	Manivannan Sadhasivam <mani@kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] PCI/portdrv: Allow probing even without child services
Date: Thu, 19 Feb 2026 18:35:42 -0800	[thread overview]
Message-ID: <aZfIfn9viQRj4uy4@google.com> (raw)
In-Reply-To: <20260219222514.GA3499908@bhelgaas>

Hi,

On Thu, Feb 19, 2026 at 04:25:14PM -0600, Bjorn Helgaas wrote:
> On Mon, Feb 09, 2026 at 05:15:35PM -0800, Brian Norris wrote:
> > The PCIe port driver fails to probe if it finds no child services,
> > presumably under the assumption that the driver is not useful in that
> > case. However, the driver *can* still be useful for power management
> > support -- namely, it still configures the port for runtime PM / D3,
> > which may be important for allowing a bridge to enter low power modes.
> > 
> > Thus, allow probe to succeed even if no IRQs and no child services are
> > available. This also mirrors existing behavior for ports that have no
> > PCIe capabilities, where we'd also probe successfully.
> > 
> > This change is a bit more important after commit f5cd8a929c82 ("PCI:
> > dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI
> > controller"), because it's common for some DWC-based systems to:
> > 
> > 1. have only have the "aer" and "pcie_pme" port services available and
> > 2. not define legacy INTx interrupts properly in their device tree.
> > 
> > After commit f5cd8a929c82, such systems may fail
> > pcie_init_service_irqs() and so exit with -ENODEV.
> > 
> > Link: https://lore.kernel.org/all/nyada24tqwlkzdceyoxbzitzygvp4elvj5oajnqdwb33xkcdwk@76vnrx45fsfd/
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> > 
> > Changes in v2:
> >  * clear master when we have no child services
> > 
> >  drivers/pci/pcie/portdrv.c | 21 +++++++--------------
> >  1 file changed, 7 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
> > index 88af0dacf351..19b08f3653ee 100644
> > --- a/drivers/pci/pcie/portdrv.c
> > +++ b/drivers/pci/pcie/portdrv.c
> > @@ -330,7 +330,7 @@ static int pcie_device_init(struct pci_dev *pdev, int service, int irq)
> >   */
> >  static int pcie_port_device_register(struct pci_dev *dev)
> >  {
> > -	int status, capabilities, i, nr_service;
> > +	int status, capabilities, i;
> >  	int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
> >  
> >  	/* Enable PCI Express port device */
> > @@ -355,29 +355,22 @@ static int pcie_port_device_register(struct pci_dev *dev)
> >  	if (status) {
> >  		capabilities &= PCIE_PORT_SERVICE_HP;
> >  		if (!capabilities)
> > -			goto error_disable;
> > +			goto out;
> >  	}
> >  
> >  	/* Allocate child services if any */
> > -	status = -ENODEV;
> > -	nr_service = 0;
> >  	for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> >  		int service = 1 << i;
> >  		if (!(capabilities & service))
> >  			continue;
> > -		if (!pcie_device_init(dev, service, irqs[i]))
> > -			nr_service++;
> > +		pcie_device_init(dev, service, irqs[i]);
> >  	}
> > -	if (!nr_service)
> > -		goto error_cleanup_irqs;
> >  
> > +out:
> > +	/* With no child services, we shouldn't need bus mastering. */
> > +	if (!capabilities)
> > +		pci_clear_master(dev);
> 
> I'm curious about this part because we pci_set_master()
> unconditionally just above:
> 
>   pci_set_master(dev);
>   pcie_init_service_irqs(dev, irqs, capabilities);
>   for (i = 0; ...; i++)
>     pcie_device_init(dev, service, irqs[i]);
>   if (!capabilities)
>     pci_clear_master(dev);
> 
> Bus mastering on a bridge must be enabled for DMA from downstream
> devices to work, but I think that's done by pci_enable_bridge() when a
> driver calls pci_enable_device() for an endpoint.
> 
> I assume the reason we call pci_set_master() here is so MSI/MSI-X from
> the bridge will work, even if there is no downstream device.
> 
> I don't think either pcie_init_service_irqs() or pcie_device_init()
> requires bus mastering, so I don't know why we enable it here.  It
> seems like we should do it when we set up MSI/MSI-X interrupts.

I'm no expert here, but by code inspection, pcie_init_service_irqs() may
call pci_msi_set_enable() which sets PCI_MSI_FLAGS_ENABLE. Could that
confuse a device to see MSI enabled but bus mastering disabled?

Brian

> If we want to do it in pcie_port_device_register() (instead of in
> service driver when they set up an interrupt), maybe we should drop
> the initial pci_set_master() and do it conditionally, e.g.,
> 
>   if (capabilities)
>     pci_set_master(dev);

  reply	other threads:[~2026-02-20  2:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10  1:15 [PATCH v2] PCI/portdrv: Allow probing even without child services Brian Norris
2026-02-19 22:25 ` Bjorn Helgaas
2026-02-20  2:35   ` Brian Norris [this message]
2026-02-20 16:40     ` Bjorn Helgaas
2026-04-09 23:20       ` Brian Norris
2026-04-09 23:41         ` Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZfIfn9viQRj4uy4@google.com \
    --to=briannorris@chromium.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mani@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.