Rafael J. Wysocki | ca589f9 | 2013-01-30 14:27:29 +0100 | [diff] [blame] | 1 | ACPI Scan Handlers |
| 2 | |
| 3 | Copyright (C) 2012, Intel Corporation |
| 4 | Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
| 5 | |
| 6 | During system initialization and ACPI-based device hot-add, the ACPI namespace |
| 7 | is scanned in search of device objects that generally represent various pieces |
| 8 | of hardware. This causes a struct acpi_device object to be created and |
| 9 | registered with the driver core for every device object in the ACPI namespace |
| 10 | and the hierarchy of those struct acpi_device objects reflects the namespace |
| 11 | layout (i.e. parent device objects in the namespace are represented by parent |
| 12 | struct acpi_device objects and analogously for their children). Those struct |
| 13 | acpi_device objects are referred to as "device nodes" in what follows, but they |
| 14 | should not be confused with struct device_node objects used by the Device Trees |
| 15 | parsing code (although their role is analogous to the role of those objects). |
| 16 | |
| 17 | During ACPI-based device hot-remove device nodes representing pieces of hardware |
| 18 | being removed are unregistered and deleted. |
| 19 | |
| 20 | The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic |
| 21 | initialization of device nodes, such as retrieving common configuration |
| 22 | information from the device objects represented by them and populating them with |
| 23 | appropriate data, but some of them require additional handling after they have |
| 24 | been registered. For example, if the given device node represents a PCI host |
| 25 | bridge, its registration should cause the PCI bus under that bridge to be |
| 26 | enumerated and PCI devices on that bus to be registered with the driver core. |
| 27 | Similarly, if the device node represents a PCI interrupt link, it is necessary |
| 28 | to configure that link so that the kernel can use it. |
| 29 | |
| 30 | Those additional configuration tasks usually depend on the type of the hardware |
| 31 | component represented by the given device node which can be determined on the |
| 32 | basis of the device node's hardware ID (HID). They are performed by objects |
| 33 | called ACPI scan handlers represented by the following structure: |
| 34 | |
| 35 | struct acpi_scan_handler { |
| 36 | const struct acpi_device_id *ids; |
| 37 | struct list_head list_node; |
| 38 | int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id); |
| 39 | void (*detach)(struct acpi_device *dev); |
| 40 | }; |
| 41 | |
| 42 | where ids is the list of IDs of device nodes the given handler is supposed to |
| 43 | take care of, list_node is the hook to the global list of ACPI scan handlers |
| 44 | maintained by the ACPI core and the .attach() and .detach() callbacks are |
| 45 | executed, respectively, after registration of new device nodes and before |
| 46 | unregistration of device nodes the handler attached to previously. |
| 47 | |
| 48 | The namespace scanning function, acpi_bus_scan(), first registers all of the |
| 49 | device nodes in the given namespace scope with the driver core. Then, it tries |
| 50 | to match a scan handler against each of them using the ids arrays of the |
| 51 | available scan handlers. If a matching scan handler is found, its .attach() |
| 52 | callback is executed for the given device node. If that callback returns 1, |
| 53 | that means that the handler has claimed the device node and is now responsible |
| 54 | for carrying out any additional configuration tasks related to it. It also will |
| 55 | be responsible for preparing the device node for unregistration in that case. |
| 56 | The device node's handler field is then populated with the address of the scan |
| 57 | handler that has claimed it. |
| 58 | |
| 59 | If the .attach() callback returns 0, it means that the device node is not |
| 60 | interesting to the given scan handler and may be matched against the next scan |
| 61 | handler in the list. If it returns a (negative) error code, that means that |
| 62 | the namespace scan should be terminated due to a serious error. The error code |
| 63 | returned should then reflect the type of the error. |
| 64 | |
| 65 | The namespace trimming function, acpi_bus_trim(), first executes .detach() |
| 66 | callbacks from the scan handlers of all device nodes in the given namespace |
| 67 | scope (if they have scan handlers). Next, it unregisters all of the device |
| 68 | nodes in that scope. |
| 69 | |
| 70 | ACPI scan handlers can be added to the list maintained by the ACPI core with the |
| 71 | help of the acpi_scan_add_handler() function taking a pointer to the new scan |
| 72 | handler as an argument. The order in which scan handlers are added to the list |
| 73 | is the order in which they are matched against device nodes during namespace |
| 74 | scans. |
| 75 | |
| 76 | All scan handles must be added to the list before acpi_bus_scan() is run for the |
| 77 | first time and they cannot be removed from it. |