On 2012-8-31 13:04, Bjorn Helgaas wrote: > On Thu, Aug 30, 2012 at 6:03 PM, Jiang Liu <jiang.liu@xxxxxxxxxx> wrote: >> On 2012-8-31 8:43, Bjorn Helgaas wrote: >>> On Thu, Aug 30, 2012 at 8:48 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >>>> On Wed, Aug 29, 2012 at 11:23 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >>> >>>>> 1) For patch [1/7], I pointed out that there is currently no way to >>>>> remove a non-ACPI host bridge, which means the fact that we don't free >>>>> the pci_sysdata is not really a leak. If you want to add the >>>>> release_fn so that you can add support for removing and adding these >>>>> non-ACPI host bridges in the future, I do not understand that. It >>>>> just doesn't make sense to me to try to support hotplug for those >>>>> bridges. >>>> >>>> for Intel Nehalem and westmere -ex system, there will be root bus from >>>> 0xf8 to 0xff for cpus. >>>> and BIOS does not put the in ACPI, but __pci_mmcfg_init will set the >>>> pcibios_last_bus. >>>> so those but get probed via pcibios_fixup_peer_bridges. >>> >>> I understand how these buses get scanned. What I don't understand is >>> what value we get from trying to make these buses hot-pluggable. >>> >>>> I hope I could use /sys to remove non-acpi root bus. >>> >>> Why? I don't think there's any value in being able to remove non-ACPI >>> host bridges. Any x86 host bridge hotplug that's actually useful to >>> users will be done via ACPI. >>> >>> You mention later that you want to remove these buses because they >>> only contain CPU devices that don't seem to be good for anything. I >>> would rather do this by simply not scanning for peer bridges in the >>> first place. That's simpler than scanning the bridge, deciding we >>> don't care about what we found, then trying to hot-remove it. > >> Actually some memory error handling mechanism may depend on those CPU >> devices to do memory address decoding. For example, EDAC needs to access >> them. And we are working on a project to do memory address translation >> by reading memory controller information from those CPU devices too. > > If you depend on those CPU-related PCI devices for EDAC or any other > reason, your BIOS should expose a host bridge leading to them. If it > does, we'll enumerate them just like we do today, and whatever host > bridge hotplug support we add should work for those bridges just like > any other host bridge. Yes, BIOS should export those PCI buses for CPU devices through ACPI, but some legacy hardware platform doesn't do that. I feel it's not worth to provide hotplug support for those PCI buses too, it just hides those PCI devices. --Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
