diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2012-12-21 00:36:39 +0100 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-01-03 13:09:36 +0100 |
commit | 805d410fb0dbd65e1a57a810858fa2491e75822d (patch) | |
tree | abd9205c523dfabd80289c40ae131a64be6b0436 /include/acpi/acpi_bus.h | |
parent | Linux 3.8-rc2 (diff) | |
download | linux-805d410fb0dbd65e1a57a810858fa2491e75822d.tar.xz linux-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.h | 1 |
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 { |