lkml.org 
[lkml]   [2012]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH 09/24] PCI, powerpc: Register busn_res for root buses
    On Fri, 10 Feb 2012 08:35:58 +1100
    Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

    > On Thu, 2012-02-09 at 11:24 -0800, Bjorn Helgaas wrote:
    > > 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.

    --
    Jesse Barnes, Intel Open Source Technology Center[unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2012-02-23 21:27    [W:0.022 / U:30.920 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site