On Thu, 23 Feb 2012 12:51:30 -0800
Bjorn Helgaas [off-list ref] wrote:

On Thu, Feb 23, 2012 at 12:25 PM, Jesse Barnes [off-list ref] wrote:

quoted

On Fri, 10 Feb 2012 08:35:58 +1100
Benjamin Herrenschmidt [off-list ref] wrote:

quoted

On Thu, 2012-02-09 at 11:24 -0800, Bjorn Helgaas wrote:

quoted

My point is that the interface between the arch and the PCI core
should be simply the arch telling the core "this is the range of bus
numbers you can use."  If the firmware doesn't give you the HW limits,
that's the arch's problem.  If you want to assume 0..255 are
available, again, that's the arch's decision.

But the answer to the question "what bus numbers are available to me"
depends only on the host bridge HW configuration.  It does not depend
on what pci_scan_child_bus() found.  Therefore, I think we can come up
with a design where pci_bus_update_busn_res_end() is unnecessary.

In an ideal world yes. In a world where there are reverse engineered
platforms on which we aren't 100% sure how thing actually work under the
hood and have the code just adapt on "what's there" (and try to fix it
up -sometimes-), thinks can get a bit murky :-)

But yes, I see your point. As for what is the "correct" setting that
needs to be done so that the patch doesn't end up a regression for us,
I'll have to dig into some ancient HW to dbl check a few things. I hope
0...255 will just work but I can't guarantee it.

What I'll probably do is constraint the core to the values in
hose->min/max, and update selected platforms to put 0..255 in there when
I know for sure they can cope.

But I think the point is, can't we intiialize the busn resource after
the first & last bus numbers have been determined?  E.g. rather than
Yinghai's current:
+       pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_busno);
+
       /* Get probe mode and perform scan */
       mode = PCI_PROBE_NORMAL;
       if (node && ppc_md.pci_probe_mode)

@@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)

               of_scan_bus(node, bus);
       }

-       if (mode == PCI_PROBE_NORMAL)
+       if (mode == PCI_PROBE_NORMAL) {
+               pci_bus_update_busn_res_end(bus, 255);
               hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
+               pci_bus_update_busn_res_end(bus, bus->subordinate);
+       }

we'd have something more like:

       /* Get probe mode and perform scan */
       mode = PCI_PROBE_NORMAL;
       if (node && ppc_md.pci_probe_mode)

@@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)

               of_scan_bus(node, bus);
       }

       if (mode == PCI_PROBE_NORMAL)
               hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);

+       pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_busno);

since we should have the final bus range by then?  Setting the end to
255 and then changing it again doesn't make sense; and definitely makes
the code hard to follow.

I have two issues here:

1) hose->last_busno is currently the highest bus number found by
pci_scan_child_bus().  If I understand correctly,
pci_bus_insert_busn_res() is supposed to update the core's idea of the
host bridge's bus number aperture.  (Actually, I guess it just updates
the *end* of the aperture, since we supply the start directly to
pci_scan_root_bus()).  The aperture and the highest bus number we
found are not related, except that we should have:

    hose->first_busno <= bus->subordinate <= hose->last_busno

If we set the aperture to [first_busno - last_busno], we artificially
prevent some hotplug.

Oh true, we'll need to allocate any extra bus number space somehow so
that hot plug of bridges is possible in the future w/o renumbering
(until our glorious future when we can move resources on the fly by
stopping drivers).

2) We already have a way to add resources to a root bus: the
pci_add_resource() used to add I/O port and MMIO apertures.  I think
it'd be a lot simpler to just use that same interface for the bus
number aperture, e.g.,

    pci_add_resource(&resources, hose->io_space);
    pci_add_resource(&resources, hose->mem_space);
    pci_add_resource(&resources, hose->busnr_space);
    bus = pci_scan_root_bus(dev, next_busno, pci_ops, sysdata, &resources);

This is actually a bit redundant, since "next_busno" should be the
same as hose->busnr_space->start.  So if we adopted this approach, we
might want to eventually drop the "next_busno" argument.

Yeah that would be nice, the call would certainly make more sense that
way.

-- 
Jesse Barnes, Intel Open Source Technology Center