cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

namespace.rst (17542B)


      1.. SPDX-License-Identifier: GPL-2.0
      2.. include:: <isonum.txt>
      3
      4===================================================
      5ACPI 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
     15Abstract
     16========
     17The Linux ACPI subsystem converts ACPI namespace objects into a Linux
     18device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
     19receiving ACPI hotplug notification events.  For each device object
     20in this hierarchy there is a corresponding symbolic link in the
     21/sys/bus/acpi/devices.
     22
     23This document illustrates the structure of the ACPI device tree.
     24
     25ACPI Definition Blocks
     26======================
     27
     28The ACPI firmware sets up RSDP (Root System Description Pointer) in the
     29system memory address space pointing to the XSDT (Extended System
     30Description Table).  The XSDT always points to the FADT (Fixed ACPI
     31Description Table) using its first entry, the data within the FADT
     32includes various fixed-length entries that describe fixed ACPI features
     33of the hardware.  The FADT contains a pointer to the DSDT
     34(Differentiated System Descripition Table).  The XSDT also contains
     35entries pointing to possibly multiple SSDTs (Secondary System
     36Description Table).
     37
     38The DSDT and SSDT data is organized in data structures called definition
     39blocks that contain definitions of various objects, including ACPI
     40control methods, encoded in AML (ACPI Machine Language).  The data block
     41of the DSDT along with the contents of SSDTs represents a hierarchical
     42data structure called the ACPI namespace whose topology reflects the
     43structure of the underlying hardware platform.
     44
     45The relationships between ACPI System Definition Tables described above
     46are 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
     80Example ACPI Namespace
     81======================
     82
     83All definition blocks are loaded into a single namespace.  The namespace
     84is a hierarchy of objects identified by names and paths.
     85The following naming conventions apply to object names in the ACPI
     86namespace:
     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
     99The 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
    192Linux ACPI Device Objects
    193=========================
    194
    195The Linux kernel's core ACPI subsystem creates struct acpi_device
    196objects for ACPI namespace objects representing devices, power resources
    197processors, thermal zones.  Those objects are exported to user space via
    198sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00.  The
    199format of their names is <bus_id:instance>, where 'bus_id' refers to the
    200ACPI namespace representation of the given object and 'instance' is used
    201for distinguishing different object of the same 'bus_id' (it is
    202two-digit decimal representation of an unsigned integer).
    203
    204The value of 'bus_id' depends on the type of the object whose name it is
    205part 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
    235The following rules apply when creating struct acpi_device objects on
    236the basis of the contents of ACPI System Description Tables (as
    237indicated by the letter in the first column and the notation in the
    238second 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
    259The third column of the above table indicates which ACPI System
    260Description Tables contain information used for the creation of the
    261struct acpi_device objects represented by the given row (xSDT means DSDT
    262or SSDT).
    263
    264The fourth column of the above table indicates the 'bus_id' generation
    265rule 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
    286Linux ACPI Physical Device Glue
    287===============================
    288
    289ACPI device (i.e. struct acpi_device) objects may be linked to other
    290objects in the Linux' device hierarchy that represent "physical" devices
    291(for example, devices on the PCI bus).  If that happens, it means that
    292the ACPI device object is a "companion" of a device otherwise
    293represented in a different way and is used (1) to provide configuration
    294information 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
    296control methods.  One ACPI device object may be linked this way to
    297multiple "physical" devices.
    298
    299If an ACPI device object is linked to a "physical" device, its sysfs
    300directory contains the "physical_node" symbolic link to the sysfs
    301directory of the target device object.  In turn, the target device's
    302sysfs directory will then contain the "firmware_node" symbolic link to
    303the sysfs directory of the companion ACPI device object.
    304The linking mechanism relies on device identification provided by the
    305ACPI namespace.  For example, if there's an ACPI namespace object
    306representing a PCI device (i.e. a device object under an ACPI namespace
    307object representing a PCI bridge) whose _ADR returns 0x00020000 and the
    308bus number of the parent PCI bridge is 0, the sysfs directory
    309representing the struct acpi_device object created for that ACPI
    310namespace object will contain the 'physical_node' symbolic link to the
    311/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
    312corresponding PCI device.
    313
    314The linking mechanism is generally bus-specific.  The core of its
    315implementation is located in the drivers/acpi/glue.c file, but there are
    316complementary parts depending on the bus types in question located
    317elsewhere.  For example, the PCI-specific part of it is located in
    318drivers/pci/pci-acpi.c.
    319
    320
    321Example Linux ACPI Device Tree
    322=================================
    323
    324The sysfs hierarchy of struct acpi_device objects corresponding to the
    325example ACPI namespace illustrated in Figure 2 with the addition of
    326fixed 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.