PnP: move pnpacpi/pnpbios_init to after PCI init (ed458df4) · Commits · 戴 / test

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>

drivers/pnp/Makefile

+4 −1

Original line number	Diff line number	Diff line
		@@ -2,12 +2,15 @@
		# Makefile for the Linux Plug-and-Play Support.
		#

		obj-y := core.o card.o driver.o resource.o manager.o support.o interface.o quirks.o system.o
		obj-y := core.o card.o driver.o resource.o manager.o support.o interface.o quirks.o

		obj-$(CONFIG_PNPACPI) += pnpacpi/
		obj-$(CONFIG_PNPBIOS) += pnpbios/
		obj-$(CONFIG_ISAPNP) += isapnp/

		# pnp_system_init goes after pnpacpi/pnpbios init
		obj-y += system.o

		ifeq ($(CONFIG_PNP_DEBUG),y)
		EXTRA_CFLAGS += -DDEBUG
		endif

drivers/pnp/pnpacpi/core.c

+1 −1

Original line number	Diff line number	Diff line
		@@ -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)
		{

drivers/pnp/pnpbios/core.c

+1 −1

Original line number	Diff line number	Diff line
		@@ -571,7 +571,7 @@ static int __init pnpbios_init(void)
		return 0;
		}

		subsys_initcall(pnpbios_init);
		fs_initcall(pnpbios_init);

		static int __init pnpbios_thread_init(void)
		{

Admin message