linux-pinenote/drivers/pnp/Makefile

#
# 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

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

# pnp_system_init goes after pnpacpi/pnpbios init
obj-y				+= system.o
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 15:20:36 -07:00			`#`
			`# Makefile for the Linux Plug-and-Play Support.`
			`#`

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> 2008-10-10 08:00:17 -07:00			`obj-y := core.o card.o driver.o resource.o manager.o support.o interface.o quirks.o`
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 15:20:36 -07:00
			`obj-$(CONFIG_PNPACPI) += pnpacpi/`
			`obj-$(CONFIG_PNPBIOS) += pnpbios/`
			`obj-$(CONFIG_ISAPNP) += isapnp/`
PNP: use dev_info(), dev_err(), etc in core If we have the struct pnp_dev available, we can use dev_info(), dev_err(), etc., to give a little more information and consistency. [akpm@linux-foundation.org: fix warning] Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Adam Belay <ambx1@neo.rr.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2007-10-16 23:31:10 -07:00
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> 2008-10-10 08:00:17 -07:00			`# pnp_system_init goes after pnpacpi/pnpbios init`
			`obj-y += system.o`