On Thu, Jan 19, 2012 at 2:13 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > On Thu, Jan 19, 2012 at 1:42 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >> please check attached patch. > > It's a pain to comment on attached patches vs. inline ones. Sorry, gmail does not allow inline patch. > > 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. Well that depends. > 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." No, struct host bridge is bad idea. you are tracking host bridge and peer root bus the same time. > > The printk %pR format supports bus numbers so you don't need to print > them by hand. later. will remove the debug print. > > 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. no, we need that to tracking the busn usage. aka insert them into iobusn_resource tree. late it should be convert to list head even. for handling transparent bridge. > > This makes pci_scan_bridge() significantly more ugly than it already > is. I think it needs to get broken up. Sure. Yinghai -- 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
