On Thursday 04 of October 2012 13:44:42 Bjorn Helgaas wrote: > 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. Agreed. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
