On Thu, Jan 19, 2012 at 1:42 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Wed, Jan 18, 2012 at 9:46 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Wed, Jan 18, 2012 at 10:27 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >>> On Wed, Jan 18, 2012 at 8:52 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >>>> If we make a quirk for this machine, we still have the question of >>>> what to do with my patches. I assert that if Linux ever reconfigures >>>> any bus numbers or does any configuration of hot-added P2P bridges, it >>>> must pay attention to the host bridge bus number window. Therefore, I >>>> think we need something like this series even if we make a quirk. >>> >>> We may need more smart way to find unused bus range instead of just >>> just max+1 and ++max. >>> >>> For example: one bridge (A) have two child bridges (B and C), >>> A: bus range: 10-2f >>> B: bus range: 11-1f >>> C: bus range: 20-2f >>> >>> when some broken case happen, B bus BIOS assigned bus range will be >>> all cleared in first pass. >>> but C bus is ok. but in second bus, bus will be assigned to 30- . >>> that is totally wrong, We should still >>> try to use bus 11-1f at first for bus B. >> >> Yes, I agree we may need a better way to choose bus numbers in the >> first place. My current patch (3/4) doesn't change how we choose >> them; it only rejects invalid ones. > > come out draft about bus number tracking and allocate bus range instead. > > please check attached patch. It's a pain to comment on attached patches vs. inline ones. You added bus_max to pci_scan_root_bus(). I'd prefer to pass a pointer to a struct resource, as we do for io & mem resources. I'd like to move away from pci_scan_root_bus() and toward a pci_scan_host_bridge() (as in the patches I posted) that takes all the host bridge-related info: parent, domain, resources (including bus number range), ops, sysdata. I don't like the current scheme of "create it with defaults and fix them later." The printk %pR format supports bus numbers so you don't need to print them by hand. struct pci_bus already has secondary & subordinate. I don't think adding a "struct resource busn_res" adds useful information except for the root bus, where the bus number range comes from something external like _CRS rather than from the upstream bridge config. This makes pci_scan_bridge() significantly more ugly than it already is. I think it needs to get broken up. -- 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
