On Fri, Oct 14, 2011 at 2:39 PM, Yinghai Lu <yinghai.lu@xxxxxxxxxx> wrote: > On 10/14/2011 01:32 PM, Bjorn Helgaas wrote: > > >>>> int node; >>>> @@ -353,11 +349,18 @@ struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_pci_root *root) >>>> memcpy(bus->sysdata, sd, sizeof(*sd)); >>>> kfree(sd); >>>> } else { >>>> - bus = pci_create_bus(NULL, busnum, &pci_root_ops, sd); >>>> - if (bus) { >>>> - get_current_resources(device, busnum, domain, bus); >>>> - bus->subordinate = pci_scan_child_bus(bus); >>>> + INIT_LIST_HEAD(&resources); >>>> + get_current_resources(device, busnum, domain, &resources); >>>> + if (!pci_use_crs) { >>>> + pci_free_resource_list(&resources); >>>> + x86_pci_root_bus_resources(busnum, &resources); >>>> } >>> >>> >>> You may need to update get_current_resources() to return status about handling _CRS... >>> and check that status insteaf of !pci_use_crs. >> >> Is the current patch broken here? I don't think it will be simpler to >> have get_current_resources() return a status and check that. But if >> something's actually broken, I want to fix it, of course. >> > > > yes. if for some reason, _CRS is not handled right, that root bus resources will not get set to default res. > > + status = get_current_resources(device, busnum, domain, &resources); > + if (status) { > + pci_free_resource_list(&resources); > + x86_pci_root_bus_resources(busnum, &resources); > } > > get_current_resources() will not return 0 if _CRS is not really used. OK. I think it was that way before, too. We created the bus with default resources, but the first thing get_current_resources() did was clear them all out. If there was a problem parsing _CRS, we never went back and put the defaults back in. But I think this will do what you suggest and is nicer than what I had before: INIT_LIST_HEAD(&resources); get_current_resources(device, busnum, domain, &resources); if (list_empty(&resources)) x86_pci_root_bus_resources(busnum, &resources); -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html