]>
Commit | Line | Data |
---|---|---|
ca589f94 RW |
1 | ACPI Scan Handlers |
2 | ||
3 | Copyright (C) 2012, Intel Corporation | |
4 | Author: Rafael J. Wysocki <[email protected]> | |
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. |