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