Re: [PATCH] PCI: workaround hard-wired bus number

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 27, 2012 at 2:11 AM, Thomas Renninger <trenn@xxxxxxx> wrote:
> From: Yinghai Lu <yinghai.lu@xxxxxxxxxx>
>
> Fixes PCI device detection on IBM xSeries IBM 3850 M2 / x3950 M2
> when using ACPI resources (_CRS).
> This is default, a manual workaround (without this patch)
> would be pci=nocrs boot param.
>
> Tested-by: garyhade@xxxxxxxxxx
> CC: trenn@xxxxxxx
> CC: bhelgaas@xxxxxxxxxx
> Signed-off-by: Thomas Renninger <trenn@xxxxxxx>
> ---
>  drivers/pci/probe.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 7cc9e2f..1e255c8 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -651,6 +651,10 @@ int __devinit pci_scan_bridge(struct pci_bus *bus, struct pci_dev *dev, int max,
>        dev_dbg(&dev->dev, "scanning [bus %02x-%02x] behind bridge, pass %d\n",
>                secondary, subordinate, pass);
>
> +       /* some bridge primary bus is hard wired to 0 */
> +       if (!primary && (primary != bus->number) && secondary && subordinate)
> +               primary = bus->number;
> +
>        /* Check if setup is sensible at all */
>        if (!pass &&
>            (primary != bus->number || secondary <= bus->number)) {
> --
> 1.7.6.1
>

I'm not thrilled with adding a machine-specific quirk in this generic
code path because future rework of this path will always have to
consider and preserve it.

I wonder whether it would be possible to set this up so we read
PCI_PRIMARY_BUS earlier, so we could update that primary bus number in
a quirk before getting into the rest of pci_scan_bridge().  That might
take non-trivial rework, since the cached copy of the primary bus
number is currently in struct pci_bus, not in struct pci_dev.  But
that in itself is non-intuitive to me: the primary, secondary, and
subordinate bus numbers are all in struct pci_bus, when they seem more
like a property of the bridge device than of the bus.

If we put something like this in mainline, I think it needs a bugzilla
reference, preferably in bugzilla.kernel.org, where the details (DMI
info, vendor/device ID of the bridge, etc.) will be public (there is a
Novell bugzilla, but I don't think it's public).

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux