public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] PCI: cpqphp: Simplify PCI_ScanBusForNonBridge()
Date: Fri, 18 Oct 2024 18:37:56 -0500	[thread overview]
Message-ID: <20241018233756.GA769880@bhelgaas> (raw)
In-Reply-To: <20241017143131.46163-5-ilpo.jarvinen@linux.intel.com>

On Thu, Oct 17, 2024 at 05:31:31PM +0300, Ilpo Järvinen wrote:
> PCI_ScanBusForNonBridge() has two loops, first searching for
> non-bridges and second that looks for bridges. The second loop has
> hints in a debug print it should do recursion for buses underneath the
> bridge but no recursion is attempted.
> 
> Since the second loop is quite useless in its current form, just
> eliminate it. This code hasn't been touched for very long time so
> either it's unused or the missing parts are not important enough for
> anyone to attempt to add them.
> 
> Leave only a simple comment about the missing recursion for the
> unlikely case that somebody comes across the lack of functionality. In
> any case, search whether an endpoint exists downstream of a bridge
> sounds generic enough to belong to core so if the functionality is to
> be extended it should probably be moved into PCI core.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
>  drivers/pci/hotplug/cpqphp_pci.c | 30 +++++++++++-------------------
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/pci/hotplug/cpqphp_pci.c b/drivers/pci/hotplug/cpqphp_pci.c
> index 558866c15e03..b2efc4a90864 100644
> --- a/drivers/pci/hotplug/cpqphp_pci.c
> +++ b/drivers/pci/hotplug/cpqphp_pci.c
> @@ -190,8 +190,7 @@ static int PCI_ScanBusForNonBridge(struct controller *ctrl, u8 bus_num, u8 *dev_
>  {
>  	u16 tdevice;
>  	u32 work;
> -	int ret;
> -	u8 tbus;
> +	int ret = -1;
>  
>  	ctrl->pci_bus->number = bus_num;
>  
> @@ -208,26 +207,19 @@ static int PCI_ScanBusForNonBridge(struct controller *ctrl, u8 bus_num, u8 *dev_
>  			*dev_num = tdevice;
>  			dbg("found it !\n");
>  			return 0;
> -		}
> -	}
> -	for (tdevice = 0; tdevice < 0xFF; tdevice++) {
> -		/* Scan for access first */
> -		if (!pci_bus_read_dev_vendor_id(ctrl->pci_bus, tdevice, &work, 0))
> -			continue;
> -		ret = pci_bus_read_config_dword(ctrl->pci_bus, tdevice, PCI_CLASS_REVISION, &work);
> -		if (ret)
> -			continue;
> -		dbg("Looking for bridge bus_num %d dev_num %d\n", bus_num, tdevice);
> -		/* Yep we got one. bridge ? */
> -		if ((work >> 8) == PCI_TO_PCI_BRIDGE_CLASS) {
> -			pci_bus_read_config_byte(ctrl->pci_bus, PCI_DEVFN(tdevice, 0), PCI_SECONDARY_BUS, &tbus);
> -			/* XXX: no recursion, wtf? */
> -			dbg("Recurse on bus_num %d tdevice %d\n", tbus, tdevice);
> -			return 0;
> +		} else {
> +			/*
> +			 * XXX: Code whose debug printout indicated
> +			 * recursion to buses underneath bridges might be
> +			 * necessary was removed because it never did
> +			 * any recursion.
> +			 */
> +			ret = 0;

I'm OK with this except that I wonder if we should leave an actual
info or even warning level printk here as a more visible debugging
hint if somebody hits this.  I'm not sure that simply returning 0
would be enough of a hint about why devices below the bridge weren't
found.

>  		}
>  	}
>  
> -	return -1;
> +
> +	return ret;
>  }
>  
>  
> -- 
> 2.39.5
> 

      reply	other threads:[~2024-10-18 23:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17 14:31 [PATCH 0/4] PCI: cpqphp: Fix and cleanups Ilpo Järvinen
2024-10-17 14:31 ` [PATCH 1/4] PCI: cpqphp: Fix PCIBIOS_* return value confusions Ilpo Järvinen
2024-10-17 14:31 ` [PATCH 2/4] PCI: cpqphp: Use pci_bus_read_dev_vendor_id() to detect presence Ilpo Järvinen
2024-10-17 14:31 ` [PATCH 3/4] PCI: cpqphp: Use define to read class/revision dword Ilpo Järvinen
2024-10-17 14:31 ` [PATCH 4/4] PCI: cpqphp: Simplify PCI_ScanBusForNonBridge() Ilpo Järvinen
2024-10-18 23:37   ` Bjorn Helgaas [this message]

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=20241018233756.GA769880@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox