summaryrefslogtreecommitdiff
path: root/drivers/pnp/pnpacpi
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2008-10-10 08:00:17 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-10-10 08:00:17 -0700
commited458df4d2470adc02762a87a9ad665d0b1a2bd4 (patch)
tree7f5a8409b5b1514e05bf54c4c666711131f6de2f /drivers/pnp/pnpacpi
parent82219fceeb654789a9dd7cd3c6cce12dbf659342 (diff)
downloadlinux-3.10-ed458df4d2470adc02762a87a9ad665d0b1a2bd4.tar.gz
linux-3.10-ed458df4d2470adc02762a87a9ad665d0b1a2bd4.tar.bz2
linux-3.10-ed458df4d2470adc02762a87a9ad665d0b1a2bd4.zip
PnP: move pnpacpi/pnpbios_init to after PCI init
We already did that a long time ago for pnp_system_init, but pnpacpi_init and pnpbios_init remained as subsys_initcalls, and get linked into the kernel before the arch-specific routines that finalize the PCI resources (pci_subsys_init). This means that the PnP routines would either register their resources before the PCI layer could, or would be unable to check whether a PCI resource had already been registered. Both are problematic. I wanted to do this before 2.6.27, but every time we change something like this, something breaks. That said, _every_ single time we trust some firmware (like PnP tables) more than we trust the hardware itself (like PCI probing), the problems have been worse. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/pnp/pnpacpi')
-rw-r--r--drivers/pnp/pnpacpi/core.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index c1b9ea34977..53561d72b4e 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -268,7 +268,7 @@ static int __init pnpacpi_init(void)
return 0;
}
-subsys_initcall(pnpacpi_init);
+fs_initcall(pnpacpi_init);
static int __init pnpacpi_setup(char *str)
{