aboutsummaryrefslogtreecommitdiffstats
path: root/include/acpi/acpi_bus.h
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2012-12-21 00:36:39 +0100
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-01-03 13:09:36 +0100
commit805d410fb0dbd65e1a57a810858fa2491e75822d (patch)
treeabd9205c523dfabd80289c40ae131a64be6b0436 /include/acpi/acpi_bus.h
parentLinux 3.8-rc2 (diff)
downloadlinux-dev-805d410fb0dbd65e1a57a810858fa2491e75822d.tar.xz
linux-dev-805d410fb0dbd65e1a57a810858fa2491e75822d.zip
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such that struct acpi_device objects are registerd in the first pass without probing ACPI drivers and the drivers are probed against them directly in the second pass. There are two main reasons for doing that. First, the ACPI PCI root bridge driver's .add() routine, acpi_pci_root_add(), causes struct pci_dev objects to be created for all PCI devices under the given root bridge. Usually, there are corresponding ACPI device nodes in the ACPI namespace for some of those devices and therefore there should be "companion" struct acpi_device objects to attach those struct pci_dev objects to. These struct acpi_device objects should exist when the corresponding struct pci_dev objects are created, but that is only guaranteed during boot and not during hotplug. This leads to a number of functional differences between the boot and the hotplug cases which are not strictly necessary and make the code more complicated. For example, this forces the ACPI PCI root bridge driver to defer the registration of the just created struct pci_dev objects and to use a special .start() callback routine, acpi_pci_root_start(), to make sure that all of the "companion" struct acpi_device objects will be present at PCI devices registration time during hotplug. If those differences can be eliminated, we will be able to consolidate the boot and hotplug code paths for the enumeration and registration of PCI devices and to reduce the complexity of that code quite a bit. The second reason is that, in general, it should be possible to resolve conflicts of resources assigned by the BIOS to different devices represented by ACPI namespace nodes before any drivers bind to them and before they are attached to "companion" objects representing physical devices (such as struct pci_dev). However, for this purpose we first need to enumerate all ACPI device nodes in the given namespace scope. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
Diffstat (limited to 'include/acpi/acpi_bus.h')
-rw-r--r--include/acpi/acpi_bus.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 7ced5dc20dd3..016918c16c98 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -98,6 +98,7 @@ typedef void (*acpi_op_notify) (struct acpi_device * device, u32 event);
struct acpi_bus_ops {
u32 acpi_op_add:1;
u32 acpi_op_start:1;
+ u32 acpi_op_match:1;
};
struct acpi_device_ops {