| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
MAINTAINERS
arch/x86/kernel/acpi/boot.c
arch/x86/kernel/acpi/sleep.c
drivers/acpi/Kconfig
drivers/pnp/Makefile
drivers/pnp/quirks.c
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
CONFIG_PNP_DEBUG is no longer used to turn on dev_dbg() in PNP,
since we have pnp_dbg() which can be enabled at boot-time, so
this patch removes the config option.
Note that pnp_dock_event() checks "#ifdef DEBUG". But there's
never been a clear path for enabling that via configgery. It
happened that CONFIG_PNP_DEBUG enabled it after 1bd17e63a068db6,
but that was accidental and only in 2.6.26.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
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>
|
|
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>
|
|
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!
|
