On Thu, Oct 4, 2012 at 12:36 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Thu, Oct 4, 2012 at 10:47 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Wed, Oct 03, 2012 at 04:00:10PM -0700, Yinghai Lu wrote: >> This is a fundamental difference: at boot-time, all the ACPI devices below the >> host bridge already exist before the pci_root.c driver claims the bridge, >> while at hot-add time, pci_root.c claims the bridge *before* those ACPI >> devices exist. >> >> I think this is wrong. The hot-plug case (where the driver is already >> loaded and binds to the device as soon as it's discovered, before the >> ACPI hierarchy below it is enumerated) seems like the obviously correct >> order. I think we should change the boot-time order to match that, i.e., >> we should register pci_root.c *before* enumerating ACPI devices. > > in booting path, all device get probed at first, and then register driver... > do you want to register all pci driver before probing pci devices? I don't think we should have dependencies either way. It shouldn't matter whether we enumerate devices first or we register the driver first. That's why I think the current PCI/ACPI binding is broken -- it assumes that we fully enumerate ACPI before the driver is registered. To answer your specific question, yes, I do think drivers that are statically built in probably should be registered before devices are enumerated. That way, the boot-time case is more similar to the hot-add case. Obviously, for drivers that can be modules, the reverse must work as well (enumerate devices, then load and register the driver). And then the other order (register driver, then enumerate device) must also work so future hot-adds of the same device type work. Bjorn -- 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
