On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
I'm sure you're right, but I don't understand why yet. Here's what I think is happening; please correct me where I'm going wrong:
- enumerate PNP & ACPI devices
- initialize PNP & ACPI drivers 2a) register ACPI PCI root bridge driver, which enumerates PCI devices behind the bridge 2b) register PNP system driver and reserve resources (this is where the current quirk skips some reservations)
- initialize PCI drivers 3a) register intel8x0 sound driver and reserve conflicting resources
So where in this would you put the
pcibios_init() -> pcibios_resource_survey()
call (it's a subsys_initcall)?
THAT is the thing that actually registers the PCI resurces we've found into the resource tree!
It's very inconveniently placed as-is, since it literally depends on the whole initcall ordering (and the link order within that subsys_initcall thing), and all of this is architecture-driven rather than driven from some central place.
So this is the thing that I think should happen before any PnP or ACPI drivers actually start registerign themselves (but obviously needs to happen after the PCI buses have been enumerated).
The ACPI/PnP tables shouldn't be able to break the enumeration of the actual hardware devices, now should it?
I think you're suggesting that we should do 2a first, to enumerate all PCI devices, and only later do 2b. But I don't know how to accomplish that cleanly.
We should enumerate the PCI devices, then register their resources (and no, I'm not at *all* convinced it should happen as a separate subsys_initcall), and then register the PnP resources.
So I think we should have roughly something like:
- arch_initcall: this could enumerate the ACPI/PnP devices (but not register anything). Alternatively, do it as subsys_initcall, and just make sure it happens early with link-order.
- subsys_initcall: this should do that pcibios_init() thing that surveys the resources (and the PCI enumeration needs to have happened before, probably in the same initcall thanks to link order)
- PnP/ACPI resource allocation *after* it, but before driver loading (which wll cause new resources to be allocated). This could be fs_initcall, or whatever (that's what things like "acpi_event_init" already do).
- regular drivers will come along much later, as part of driver_initcall, and by the time this happens, we've now reserved all resources we know about.
Basically, we just want to register the most trust-worthy resources before we register anything less trust-worthy. And actual device probing simply tends to be more trust-worthy than any randomly broken ACPI/PnP tables.
Linus