Documentation/firmware-guide/acpi/namespace.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2 .. include:: <isonum.txt>
   3
   4 ===================================================
   5 ACPI Device Tree - Representation of ACPI Namespace
   6 ===================================================
   7
   8 :Copyright: |copy| 2013, Intel Corporation
   9
  10 :Author: Lv Zheng <lv.zheng@intel.com>
  11
  12 :Credit:   Thanks for the help from Zhang Rui <rui.zhang@intel.com> and
  13            Rafael J.Wysocki <rafael.j.wysocki@intel.com>.
  14
  15 Abstract
  16 ========
  17 The Linux ACPI subsystem converts ACPI namespace objects into a Linux
  18 device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
  19 receiving ACPI hotplug notification events.  For each device object
  20 in this hierarchy there is a corresponding symbolic link in the
  21 /sys/bus/acpi/devices.
  22
  23 This document illustrates the structure of the ACPI device tree.
  24
  25 ACPI Definition Blocks
  26 ======================
  27
  28 The ACPI firmware sets up RSDP (Root System Description Pointer) in the
  29 system memory address space pointing to the XSDT (Extended System
  30 Description Table).  The XSDT always points to the FADT (Fixed ACPI
  31 Description Table) using its first entry, the data within the FADT
  32 includes various fixed-length entries that describe fixed ACPI features
  33 of the hardware.  The FADT contains a pointer to the DSDT
  34 (Differentiated System Descripition Table).  The XSDT also contains
  35 entries pointing to possibly multiple SSDTs (Secondary System
  36 Description Table).
  37
  38 The DSDT and SSDT data is organized in data structures called definition
  39 blocks that contain definitions of various objects, including ACPI
  40 control methods, encoded in AML (ACPI Machine Language).  The data block
  41 of the DSDT along with the contents of SSDTs represents a hierarchical
  42 data structure called the ACPI namespace whose topology reflects the
  43 structure of the underlying hardware platform.
  44
  45 The relationships between ACPI System Definition Tables described above
  46 are illustrated in the following diagram::
  47
  48    +---------+    +-------+    +--------+    +------------------------+
  49    |  RSDP   | +->| XSDT  | +->|  FADT  |    |  +-------------------+ |
  50    +---------+ |  +-------+ |  +--------+  +-|->|       DSDT        | |
  51    | Pointer | |  | Entry |-+  | ...... |  | |  +-------------------+ |
  52    +---------+ |  +-------+    | X_DSDT |--+ |  | Definition Blocks | |
  53    | Pointer |-+  | ..... |    | ...... |    |  +-------------------+ |
  54    +---------+    +-------+    +--------+    |  +-------------------+ |
  55                   | Entry |------------------|->|       SSDT        | |
  56                   +- - - -+                  |  +-------------------| |
  57                   | Entry | - - - - - - - -+ |  | Definition Blocks | |
  58                   +- - - -+                | |  +-------------------+ |
  59                                            | |  +- - - - - - - - - -+ |
  60                                            +-|->|       SSDT        | |
  61                                              |  +-------------------+ |
  62                                              |  | Definition Blocks | |
  63                                              |  +- - - - - - - - - -+ |
  64                                              +------------------------+
  65                                                           |
  66                                              OSPM Loading |
  67                                                          \|/
  68                                                    +----------------+
  69                                                    | ACPI Namespace |
  70                                                    +----------------+
  71
  72                   Figure 1. ACPI Definition Blocks
  73
  74 .. note:: RSDP can also contain a pointer to the RSDT (Root System
  75    Description Table).  Platforms provide RSDT to enable
  76    compatibility with ACPI 1.0 operating systems.  The OS is expected
  77    to use XSDT, if present.
  78
  79
  80 Example ACPI Namespace
  81 ======================
  82
  83 All definition blocks are loaded into a single namespace.  The namespace
  84 is a hierarchy of objects identified by names and paths.
  85 The following naming conventions apply to object names in the ACPI
  86 namespace:
  87
  88    1. All names are 32 bits long.
  89    2. The first byte of a name must be one of 'A' - 'Z', '_'.
  90    3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
  91       - '9', '_'.
  92    4. Names starting with '_' are reserved by the ACPI specification.
  93    5. The '\' symbol represents the root of the namespace (i.e. names
  94       prepended with '\' are relative to the namespace root).
  95    6. The '^' symbol represents the parent of the current namespace node
  96       (i.e. names prepended with '^' are relative to the parent of the
  97       current namespace node).
  98
  99 The figure below shows an example ACPI namespace::
 100
 101    +------+
 102    | \    |                     Root
 103    +------+
 104      |
 105      | +------+
 106      +-| _PR  |                 Scope(_PR): the processor namespace
 107      | +------+
 108      |   |
 109      |   | +------+
 110      |   +-| CPU0 |             Processor(CPU0): the first processor
 111      |     +------+
 112      |
 113      | +------+
 114      +-| _SB  |                 Scope(_SB): the system bus namespace
 115      | +------+
 116      |   |
 117      |   | +------+
 118      |   +-| LID0 |             Device(LID0); the lid device
 119      |   | +------+
 120      |   |   |
 121      |   |   | +------+
 122      |   |   +-| _HID |         Name(_HID, "PNP0C0D"): the hardware ID
 123      |   |   | +------+
 124      |   |   |
 125      |   |   | +------+
 126      |   |   +-| _STA |         Method(_STA): the status control method
 127      |   |     +------+
 128      |   |
 129      |   | +------+
 130      |   +-| PCI0 |             Device(PCI0); the PCI root bridge
 131      |     +------+
 132      |       |
 133      |       | +------+
 134      |       +-| _HID |         Name(_HID, "PNP0A08"): the hardware ID
 135      |       | +------+
 136      |       |
 137      |       | +------+
 138      |       +-| _CID |         Name(_CID, "PNP0A03"): the compatible ID
 139      |       | +------+
 140      |       |
 141      |       | +------+
 142      |       +-| RP03 |         Scope(RP03): the PCI0 power scope
 143      |       | +------+
 144      |       |   |
 145      |       |   | +------+
 146      |       |   +-| PXP3 |     PowerResource(PXP3): the PCI0 power resource
 147      |       |     +------+
 148      |       |
 149      |       | +------+
 150      |       +-| GFX0 |         Device(GFX0): the graphics adapter
 151      |         +------+
 152      |           |
 153      |           | +------+
 154      |           +-| _ADR |     Name(_ADR, 0x00020000): the PCI bus address
 155      |           | +------+
 156      |           |
 157      |           | +------+
 158      |           +-| DD01 |     Device(DD01): the LCD output device
 159      |             +------+
 160      |               |
 161      |               | +------+
 162      |               +-| _BCL | Method(_BCL): the backlight control method
 163      |                 +------+
 164      |
 165      | +------+
 166      +-| _TZ  |                 Scope(_TZ): the thermal zone namespace
 167      | +------+
 168      |   |
 169      |   | +------+
 170      |   +-| FN00 |             PowerResource(FN00): the FAN0 power resource
 171      |   | +------+
 172      |   |
 173      |   | +------+
 174      |   +-| FAN0 |             Device(FAN0): the FAN0 cooling device
 175      |   | +------+
 176      |   |   |
 177      |   |   | +------+
 178      |   |   +-| _HID |         Name(_HID, "PNP0A0B"): the hardware ID
 179      |   |     +------+
 180      |   |
 181      |   | +------+
 182      |   +-| TZ00 |             ThermalZone(TZ00); the FAN thermal zone
 183      |     +------+
 184      |
 185      | +------+
 186      +-| _GPE |                 Scope(_GPE): the GPE namespace
 187        +------+
 188
 189                      Figure 2. Example ACPI Namespace
 190
 191
 192 Linux ACPI Device Objects
 193 =========================
 194
 195 The Linux kernel's core ACPI subsystem creates struct acpi_device
 196 objects for ACPI namespace objects representing devices, power resources
 197 processors, thermal zones.  Those objects are exported to user space via
 198 sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00.  The
 199 format of their names is <bus_id:instance>, where 'bus_id' refers to the
 200 ACPI namespace representation of the given object and 'instance' is used
 201 for distinguishing different object of the same 'bus_id' (it is
 202 two-digit decimal representation of an unsigned integer).
 203
 204 The value of 'bus_id' depends on the type of the object whose name it is
 205 part of as listed in the table below::
 206
 207                 +---+-----------------+-------+----------+
 208                 |   | Object/Feature  | Table | bus_id   |
 209                 +---+-----------------+-------+----------+
 210                 | N | Root            | xSDT  | LNXSYSTM |
 211                 +---+-----------------+-------+----------+
 212                 | N | Device          | xSDT  | _HID     |
 213                 +---+-----------------+-------+----------+
 214                 | N | Processor       | xSDT  | LNXCPU   |
 215                 +---+-----------------+-------+----------+
 216                 | N | ThermalZone     | xSDT  | LNXTHERM |
 217                 +---+-----------------+-------+----------+
 218                 | N | PowerResource   | xSDT  | LNXPOWER |
 219                 +---+-----------------+-------+----------+
 220                 | N | Other Devices   | xSDT  | device   |
 221                 +---+-----------------+-------+----------+
 222                 | F | PWR_BUTTON      | FADT  | LNXPWRBN |
 223                 +---+-----------------+-------+----------+
 224                 | F | SLP_BUTTON      | FADT  | LNXSLPBN |
 225                 +---+-----------------+-------+----------+
 226                 | M | Video Extension | xSDT  | LNXVIDEO |
 227                 +---+-----------------+-------+----------+
 228                 | M | ATA Controller  | xSDT  | LNXIOBAY |
 229                 +---+-----------------+-------+----------+
 230                 | M | Docking Station | xSDT  | LNXDOCK  |
 231                 +---+-----------------+-------+----------+
 232
 233                  Table 1. ACPI Namespace Objects Mapping
 234
 235 The following rules apply when creating struct acpi_device objects on
 236 the basis of the contents of ACPI System Description Tables (as
 237 indicated by the letter in the first column and the notation in the
 238 second column of the table above):
 239
 240    N:
 241       The object's source is an ACPI namespace node (as indicated by the
 242       named object's type in the second column).  In that case the object's
 243       directory in sysfs will contain the 'path' attribute whose value is
 244       the full path to the node from the namespace root.
 245    F:
 246       The struct acpi_device object is created for a fixed hardware
 247       feature (as indicated by the fixed feature flag's name in the second
 248       column), so its sysfs directory will not contain the 'path'
 249       attribute.
 250    M:
 251       The struct acpi_device object is created for an ACPI namespace node
 252       with specific control methods (as indicated by the ACPI defined
 253       device's type in the second column).  The 'path' attribute containing
 254       its namespace path will be present in its sysfs directory.  For
 255       example, if the _BCL method is present for an ACPI namespace node, a
 256       struct acpi_device object with LNXVIDEO 'bus_id' will be created for
 257       it.
 258
 259 The third column of the above table indicates which ACPI System
 260 Description Tables contain information used for the creation of the
 261 struct acpi_device objects represented by the given row (xSDT means DSDT
 262 or SSDT).
 263
 264 The fourth column of the above table indicates the 'bus_id' generation
 265 rule of the struct acpi_device object:
 266
 267    _HID:
 268       _HID in the last column of the table means that the object's bus_id
 269       is derived from the _HID/_CID identification objects present under
 270       the corresponding ACPI namespace node. The object's sysfs directory
 271       will then contain the 'hid' and 'modalias' attributes that can be
 272       used to retrieve the _HID and _CIDs of that object.
 273    LNXxxxxx:
 274       The 'modalias' attribute is also present for struct acpi_device
 275       objects having bus_id of the "LNXxxxxx" form (pseudo devices), in
 276       which cases it contains the bus_id string itself.
 277    device:
 278       'device' in the last column of the table indicates that the object's
 279       bus_id cannot be determined from _HID/_CID of the corresponding
 280       ACPI namespace node, although that object represents a device (for
 281       example, it may be a PCI device with _ADR defined and without _HID
 282       or _CID).  In that case the string 'device' will be used as the
 283       object's bus_id.
 284
 285
 286 Linux ACPI Physical Device Glue
 287 ===============================
 288
 289 ACPI device (i.e. struct acpi_device) objects may be linked to other
 290 objects in the Linux' device hierarchy that represent "physical" devices
 291 (for example, devices on the PCI bus).  If that happens, it means that
 292 the ACPI device object is a "companion" of a device otherwise
 293 represented in a different way and is used (1) to provide configuration
 294 information on that device which cannot be obtained by other means and
 295 (2) to do specific things to the device with the help of its ACPI
 296 control methods.  One ACPI device object may be linked this way to
 297 multiple "physical" devices.
 298
 299 If an ACPI device object is linked to a "physical" device, its sysfs
 300 directory contains the "physical_node" symbolic link to the sysfs
 301 directory of the target device object.  In turn, the target device's
 302 sysfs directory will then contain the "firmware_node" symbolic link to
 303 the sysfs directory of the companion ACPI device object.
 304 The linking mechanism relies on device identification provided by the
 305 ACPI namespace.  For example, if there's an ACPI namespace object
 306 representing a PCI device (i.e. a device object under an ACPI namespace
 307 object representing a PCI bridge) whose _ADR returns 0x00020000 and the
 308 bus number of the parent PCI bridge is 0, the sysfs directory
 309 representing the struct acpi_device object created for that ACPI
 310 namespace object will contain the 'physical_node' symbolic link to the
 311 /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
 312 corresponding PCI device.
 313
 314 The linking mechanism is generally bus-specific.  The core of its
 315 implementation is located in the drivers/acpi/glue.c file, but there are
 316 complementary parts depending on the bus types in question located
 317 elsewhere.  For example, the PCI-specific part of it is located in
 318 drivers/pci/pci-acpi.c.
 319
 320
 321 Example Linux ACPI Device Tree
 322 =================================
 323
 324 The sysfs hierarchy of struct acpi_device objects corresponding to the
 325 example ACPI namespace illustrated in Figure 2 with the addition of
 326 fixed PWR_BUTTON/SLP_BUTTON devices is shown below::
 327
 328    +--------------+---+-----------------+
 329    | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
 330    +--------------+---+-----------------+
 331      |
 332      | +-------------+-----+----------------+
 333      +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |
 334      | +-------------+-----+----------------+
 335      |
 336      | +-------------+-----+----------------+
 337      +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |
 338      | +-------------+-----+----------------+
 339      |
 340      | +-----------+------------+--------------+
 341      +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |
 342      | +-----------+------------+--------------+
 343      |
 344      | +-------------+-------+----------------+
 345      +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |
 346      | +-------------+-------+----------------+
 347      |   |
 348      |   | +- - - - - - - +- - - - - - +- - - - - - - -+
 349      |   +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
 350      |   | +- - - - - - - +- - - - - - +- - - - - - - -+
 351      |   |
 352      |   | +------------+------------+-----------------------+
 353      |   +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |
 354      |     +------------+------------+-----------------------+
 355      |       |
 356      |       | +-----------+-----------------+-----+
 357      |       +-| device:00 | \_SB_.PCI0.RP03 | N/A |
 358      |       | +-----------+-----------------+-----+
 359      |       |   |
 360      |       |   | +-------------+----------------------+----------------+
 361      |       |   +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |
 362      |       |     +-------------+----------------------+----------------+
 363      |       |
 364      |       | +-------------+-----------------+----------------+
 365      |       +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |
 366      |         +-------------+-----------------+----------------+
 367      |           |
 368      |           | +-----------+-----------------+-----+
 369      |           +-| device:01 | \_SB_.PCI0.DD01 | N/A |
 370      |             +-----------+-----------------+-----+
 371      |
 372      | +-------------+-------+----------------+
 373      +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |
 374        +-------------+-------+----------------+
 375          |
 376          | +-------------+------------+----------------+
 377          +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |
 378          | +-------------+------------+----------------+
 379          |
 380          | +------------+------------+---------------+
 381          +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |
 382          | +------------+------------+---------------+
 383          |
 384          | +-------------+------------+----------------+
 385          +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |
 386            +-------------+------------+----------------+
 387
 388                   Figure 3. Example Linux ACPI Device Tree
 389
 390 .. note:: Each node is represented as "object/path/modalias", where:
 391
 392    1. 'object' is the name of the object's directory in sysfs.
 393    2. 'path' is the ACPI namespace path of the corresponding
 394       ACPI namespace object, as returned by the object's 'path'
 395       sysfs attribute.
 396    3. 'modalias' is the value of the object's 'modalias' sysfs
 397       attribute (as described earlier in this document).
 398
 399 .. note:: N/A indicates the device object does not have the 'path' or the
 400    'modalias' attribute.