On Mon, Mar 12, 2012 at 8:22 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > On Sat, Mar 10, 2012 at 12:00 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >> It is from acpiphp_glue.c >> >> How to use it? >> Find out root bus number to acpi root name mapping from dmesg or /sys >> >> echo "\_SB.PCIB 0" > /proc/acpi/sci/notify >> to add it back > > Nope. That might be a way to exercise this for debug purposes (and it > only works when /proc/acpi/sci/notify is compiled in), but we > definitely don't want normal users to deal with ACPI pathnames like > this. before this patch set, only way is: Users really put one root bus in and press buton etc to trigger notification to get it work. > > Most of this functionality belongs in the ACPI core, not here. The > core should be handling these notify events and turning them into > .add() and .remove() calls to the driver. > > But since the ACPI core doesn't do that yet, we have to do it in the > driver, like we do for CPU, memory, etc. That part is fine. But I > think it at least belongs *in* the driver, i.e., in pci_root.c, not in > a new pci_root_hp.c file. don't want to pollute pci_root.c. in separated file, we can use CONFIG_HOTPLUG in Makefile instead of pci_root.c > > There definitely should not be another acpi_walk_namespace() and > another list of ACPI host bridges. The core *does* already walk the > namespace and call acpi_pci_root_add() for us. And the driver already > has a list of host bridges (acpi_pci_roots). no, we may not have acpi_pci_root there. -- 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
