| xj | b04a402 | 2021-11-25 15:01:52 +0800 | [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. |