linux/Documentation/arm64/acpi_object_usage.rst
<<
>>
Prefs
   1===========
   2ACPI Tables
   3===========
   4
   5The expectations of individual ACPI tables are discussed in the list that
   6follows.
   7
   8If a section number is used, it refers to a section number in the ACPI
   9specification where the object is defined.  If "Signature Reserved" is used,
  10the table signature (the first four bytes of the table) is the only portion
  11of the table recognized by the specification, and the actual table is defined
  12outside of the UEFI Forum (see Section 5.2.6 of the specification).
  13
  14For ACPI on arm64, tables also fall into the following categories:
  15
  16       -  Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
  17
  18       -  Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
  19
  20       -  Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IORT,
  21          MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO,
  22          TCPA, TPM2, UEFI, XENV
  23
  24       -  Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT,
  25          MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
  26
  27====== ========================================================================
  28Table  Usage for ARMv8 Linux
  29====== ========================================================================
  30BERT   Section 18.3 (signature == "BERT")
  31
  32       **Boot Error Record Table**
  33
  34       Must be supplied if RAS support is provided by the platform.  It
  35       is recommended this table be supplied.
  36
  37BOOT   Signature Reserved (signature == "BOOT")
  38
  39       **simple BOOT flag table**
  40
  41       Microsoft only table, will not be supported.
  42
  43BGRT   Section 5.2.22 (signature == "BGRT")
  44
  45       **Boot Graphics Resource Table**
  46
  47       Optional, not currently supported, with no real use-case for an
  48       ARM server.
  49
  50CPEP   Section 5.2.18 (signature == "CPEP")
  51
  52       **Corrected Platform Error Polling table**
  53
  54       Optional, not currently supported, and not recommended until such
  55       time as ARM-compatible hardware is available, and the specification
  56       suitably modified.
  57
  58CSRT   Signature Reserved (signature == "CSRT")
  59
  60       **Core System Resources Table**
  61
  62       Optional, not currently supported.
  63
  64DBG2   Signature Reserved (signature == "DBG2")
  65
  66       **DeBuG port table 2**
  67
  68       License has changed and should be usable.  Optional if used instead
  69       of earlycon=<device> on the command line.
  70
  71DBGP   Signature Reserved (signature == "DBGP")
  72
  73       **DeBuG Port table**
  74
  75       Microsoft only table, will not be supported.
  76
  77DSDT   Section 5.2.11.1 (signature == "DSDT")
  78
  79       **Differentiated System Description Table**
  80
  81       A DSDT is required; see also SSDT.
  82
  83       ACPI tables contain only one DSDT but can contain one or more SSDTs,
  84       which are optional.  Each SSDT can only add to the ACPI namespace,
  85       but cannot modify or replace anything in the DSDT.
  86
  87DMAR   Signature Reserved (signature == "DMAR")
  88
  89       **DMA Remapping table**
  90
  91       x86 only table, will not be supported.
  92
  93DRTM   Signature Reserved (signature == "DRTM")
  94
  95       **Dynamic Root of Trust for Measurement table**
  96
  97       Optional, not currently supported.
  98
  99ECDT   Section 5.2.16 (signature == "ECDT")
 100
 101       **Embedded Controller Description Table**
 102
 103       Optional, not currently supported, but could be used on ARM if and
 104       only if one uses the GPE_BIT field to represent an IRQ number, since
 105       there are no GPE blocks defined in hardware reduced mode.  This would
 106       need to be modified in the ACPI specification.
 107
 108EINJ   Section 18.6 (signature == "EINJ")
 109
 110       **Error Injection table**
 111
 112       This table is very useful for testing platform response to error
 113       conditions; it allows one to inject an error into the system as
 114       if it had actually occurred.  However, this table should not be
 115       shipped with a production system; it should be dynamically loaded
 116       and executed with the ACPICA tools only during testing.
 117
 118ERST   Section 18.5 (signature == "ERST")
 119
 120       **Error Record Serialization Table**
 121
 122       On a platform supports RAS, this table must be supplied if it is not
 123       UEFI-based; if it is UEFI-based, this table may be supplied. When this
 124       table is not present, UEFI run time service will be utilized to save
 125       and retrieve hardware error information to and from a persistent store.
 126
 127ETDT   Signature Reserved (signature == "ETDT")
 128
 129       **Event Timer Description Table**
 130
 131       Obsolete table, will not be supported.
 132
 133FACS   Section 5.2.10 (signature == "FACS")
 134
 135       **Firmware ACPI Control Structure**
 136
 137       It is unlikely that this table will be terribly useful.  If it is
 138       provided, the Global Lock will NOT be used since it is not part of
 139       the hardware reduced profile, and only 64-bit address fields will
 140       be considered valid.
 141
 142FADT   Section 5.2.9 (signature == "FACP")
 143
 144       **Fixed ACPI Description Table**
 145       Required for arm64.
 146
 147
 148       The HW_REDUCED_ACPI flag must be set.  All of the fields that are
 149       to be ignored when HW_REDUCED_ACPI is set are expected to be set to
 150       zero.
 151
 152       If an FACS table is provided, the X_FIRMWARE_CTRL field is to be
 153       used, not FIRMWARE_CTRL.
 154
 155       If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is
 156       filled in properly - that the PSCI_COMPLIANT flag is set and that
 157       PSCI_USE_HVC is set or unset as needed (see table 5-37).
 158
 159       For the DSDT that is also required, the X_DSDT field is to be used,
 160       not the DSDT field.
 161
 162FPDT   Section 5.2.23 (signature == "FPDT")
 163
 164       **Firmware Performance Data Table**
 165
 166       Optional, not currently supported.
 167
 168GTDT   Section 5.2.24 (signature == "GTDT")
 169
 170       **Generic Timer Description Table**
 171
 172       Required for arm64.
 173
 174HEST   Section 18.3.2 (signature == "HEST")
 175
 176       **Hardware Error Source Table**
 177
 178       ARM-specific error sources have been defined; please use those or the
 179       PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
 180       Bridge), or use type 9 (Generic Hardware Error Source).  Firmware first
 181       error handling is possible if and only if Trusted Firmware is being
 182       used on arm64.
 183
 184       Must be supplied if RAS support is provided by the platform.  It
 185       is recommended this table be supplied.
 186
 187HPET   Signature Reserved (signature == "HPET")
 188
 189       **High Precision Event timer Table**
 190
 191       x86 only table, will not be supported.
 192
 193IBFT   Signature Reserved (signature == "IBFT")
 194
 195       **iSCSI Boot Firmware Table**
 196
 197       Microsoft defined table, support TBD.
 198
 199IORT   Signature Reserved (signature == "IORT")
 200
 201       **Input Output Remapping Table**
 202
 203       arm64 only table, required in order to describe IO topology, SMMUs,
 204       and GIC ITSs, and how those various components are connected together,
 205       such as identifying which components are behind which SMMUs/ITSs.
 206       This table will only be required on certain SBSA platforms (e.g.,
 207       when using GICv3-ITS and an SMMU); on SBSA Level 0 platforms, it
 208       remains optional.
 209
 210IVRS   Signature Reserved (signature == "IVRS")
 211
 212       **I/O Virtualization Reporting Structure**
 213
 214       x86_64 (AMD) only table, will not be supported.
 215
 216LPIT   Signature Reserved (signature == "LPIT")
 217
 218       **Low Power Idle Table**
 219
 220       x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor
 221       descriptions and power states on ARM platforms should use the DSDT
 222       and define processor container devices (_HID ACPI0010, Section 8.4,
 223       and more specifically 8.4.3 and and 8.4.4).
 224
 225MADT   Section 5.2.12 (signature == "APIC")
 226
 227       **Multiple APIC Description Table**
 228
 229       Required for arm64.  Only the GIC interrupt controller structures
 230       should be used (types 0xA - 0xF).
 231
 232MCFG   Signature Reserved (signature == "MCFG")
 233
 234       **Memory-mapped ConFiGuration space**
 235
 236       If the platform supports PCI/PCIe, an MCFG table is required.
 237
 238MCHI   Signature Reserved (signature == "MCHI")
 239
 240       **Management Controller Host Interface table**
 241
 242       Optional, not currently supported.
 243
 244MPST   Section 5.2.21 (signature == "MPST")
 245
 246       **Memory Power State Table**
 247
 248       Optional, not currently supported.
 249
 250MSCT   Section 5.2.19 (signature == "MSCT")
 251
 252       **Maximum System Characteristic Table**
 253
 254       Optional, not currently supported.
 255
 256MSDM   Signature Reserved (signature == "MSDM")
 257
 258       **Microsoft Data Management table**
 259
 260       Microsoft only table, will not be supported.
 261
 262NFIT   Section 5.2.25 (signature == "NFIT")
 263
 264       **NVDIMM Firmware Interface Table**
 265
 266       Optional, not currently supported.
 267
 268OEMx   Signature of "OEMx" only
 269
 270       **OEM Specific Tables**
 271
 272       All tables starting with a signature of "OEM" are reserved for OEM
 273       use.  Since these are not meant to be of general use but are limited
 274       to very specific end users, they are not recommended for use and are
 275       not supported by the kernel for arm64.
 276
 277PCCT   Section 14.1 (signature == "PCCT)
 278
 279       **Platform Communications Channel Table**
 280
 281       Recommend for use on arm64; use of PCC is recommended when using CPPC
 282       to control performance and power for platform processors.
 283
 284PMTT   Section 5.2.21.12 (signature == "PMTT")
 285
 286       **Platform Memory Topology Table**
 287
 288       Optional, not currently supported.
 289
 290PSDT   Section 5.2.11.3 (signature == "PSDT")
 291
 292       **Persistent System Description Table**
 293
 294       Obsolete table, will not be supported.
 295
 296RASF   Section 5.2.20 (signature == "RASF")
 297
 298       **RAS Feature table**
 299
 300       Optional, not currently supported.
 301
 302RSDP   Section 5.2.5 (signature == "RSD PTR")
 303
 304       **Root System Description PoinTeR**
 305
 306       Required for arm64.
 307
 308RSDT   Section 5.2.7 (signature == "RSDT")
 309
 310       **Root System Description Table**
 311
 312       Since this table can only provide 32-bit addresses, it is deprecated
 313       on arm64, and will not be used.  If provided, it will be ignored.
 314
 315SBST   Section 5.2.14 (signature == "SBST")
 316
 317       **Smart Battery Subsystem Table**
 318
 319       Optional, not currently supported.
 320
 321SLIC   Signature Reserved (signature == "SLIC")
 322
 323       **Software LIcensing table**
 324
 325       Microsoft only table, will not be supported.
 326
 327SLIT   Section 5.2.17 (signature == "SLIT")
 328
 329       **System Locality distance Information Table**
 330
 331       Optional in general, but required for NUMA systems.
 332
 333SPCR   Signature Reserved (signature == "SPCR")
 334
 335       **Serial Port Console Redirection table**
 336
 337       Required for arm64.
 338
 339SPMI   Signature Reserved (signature == "SPMI")
 340
 341       **Server Platform Management Interface table**
 342
 343       Optional, not currently supported.
 344
 345SRAT   Section 5.2.16 (signature == "SRAT")
 346
 347       **System Resource Affinity Table**
 348
 349       Optional, but if used, only the GICC Affinity structures are read.
 350       To support arm64 NUMA, this table is required.
 351
 352SSDT   Section 5.2.11.2 (signature == "SSDT")
 353
 354       **Secondary System Description Table**
 355
 356       These tables are a continuation of the DSDT; these are recommended
 357       for use with devices that can be added to a running system, but can
 358       also serve the purpose of dividing up device descriptions into more
 359       manageable pieces.
 360
 361       An SSDT can only ADD to the ACPI namespace.  It cannot modify or
 362       replace existing device descriptions already in the namespace.
 363
 364       These tables are optional, however.  ACPI tables should contain only
 365       one DSDT but can contain many SSDTs.
 366
 367STAO   Signature Reserved (signature == "STAO")
 368
 369       **_STA Override table**
 370
 371       Optional, but only necessary in virtualized environments in order to
 372       hide devices from guest OSs.
 373
 374TCPA   Signature Reserved (signature == "TCPA")
 375
 376       **Trusted Computing Platform Alliance table**
 377
 378       Optional, not currently supported, and may need changes to fully
 379       interoperate with arm64.
 380
 381TPM2   Signature Reserved (signature == "TPM2")
 382
 383       **Trusted Platform Module 2 table**
 384
 385       Optional, not currently supported, and may need changes to fully
 386       interoperate with arm64.
 387
 388UEFI   Signature Reserved (signature == "UEFI")
 389
 390       **UEFI ACPI data table**
 391
 392       Optional, not currently supported.  No known use case for arm64,
 393       at present.
 394
 395WAET   Signature Reserved (signature == "WAET")
 396
 397       **Windows ACPI Emulated devices Table**
 398
 399       Microsoft only table, will not be supported.
 400
 401WDAT   Signature Reserved (signature == "WDAT")
 402
 403       **Watch Dog Action Table**
 404
 405       Microsoft only table, will not be supported.
 406
 407WDRT   Signature Reserved (signature == "WDRT")
 408
 409       **Watch Dog Resource Table**
 410
 411       Microsoft only table, will not be supported.
 412
 413WPBT   Signature Reserved (signature == "WPBT")
 414
 415       **Windows Platform Binary Table**
 416
 417       Microsoft only table, will not be supported.
 418
 419XENV   Signature Reserved (signature == "XENV")
 420
 421       **Xen project table**
 422
 423       Optional, used only by Xen at present.
 424
 425XSDT   Section 5.2.8 (signature == "XSDT")
 426
 427       **eXtended System Description Table**
 428
 429       Required for arm64.
 430====== ========================================================================
 431
 432ACPI Objects
 433------------
 434The expectations on individual ACPI objects that are likely to be used are
 435shown in the list that follows; any object not explicitly mentioned below
 436should be used as needed for a particular platform or particular subsystem,
 437such as power management or PCI.
 438
 439===== ================ ========================================================
 440Name   Section         Usage for ARMv8 Linux
 441===== ================ ========================================================
 442_CCA   6.2.17          This method must be defined for all bus masters
 443                       on arm64 - there are no assumptions made about
 444                       whether such devices are cache coherent or not.
 445                       The _CCA value is inherited by all descendants of
 446                       these devices so it does not need to be repeated.
 447                       Without _CCA on arm64, the kernel does not know what
 448                       to do about setting up DMA for the device.
 449
 450                       NB: this method provides default cache coherency
 451                       attributes; the presence of an SMMU can be used to
 452                       modify that, however.  For example, a master could
 453                       default to non-coherent, but be made coherent with
 454                       the appropriate SMMU configuration (see Table 17 of
 455                       the IORT specification, ARM Document DEN 0049B).
 456
 457_CID   6.1.2           Use as needed, see also _HID.
 458
 459_CLS   6.1.3           Use as needed, see also _HID.
 460
 461_CPC   8.4.7.1         Use as needed, power management specific.  CPPC is
 462                       recommended on arm64.
 463
 464_CRS   6.2.2           Required on arm64.
 465
 466_CSD   8.4.2.2         Use as needed, used only in conjunction with _CST.
 467
 468_CST   8.4.2.1         Low power idle states (8.4.4) are recommended instead
 469                       of C-states.
 470
 471_DDN   6.1.4           This field can be used for a device name.  However,
 472                       it is meant for DOS device names (e.g., COM1), so be
 473                       careful of its use across OSes.
 474
 475_DSD   6.2.5           To be used with caution.  If this object is used, try
 476                       to use it within the constraints already defined by the
 477                       Device Properties UUID.  Only in rare circumstances
 478                       should it be necessary to create a new _DSD UUID.
 479
 480                       In either case, submit the _DSD definition along with
 481                       any driver patches for discussion, especially when
 482                       device properties are used.  A driver will not be
 483                       considered complete without a corresponding _DSD
 484                       description.  Once approved by kernel maintainers,
 485                       the UUID or device properties must then be registered
 486                       with the UEFI Forum; this may cause some iteration as
 487                       more than one OS will be registering entries.
 488
 489_DSM   9.1.1           Do not use this method.  It is not standardized, the
 490                       return values are not well documented, and it is
 491                       currently a frequent source of error.
 492
 493\_GL   5.7.1           This object is not to be used in hardware reduced
 494                       mode, and therefore should not be used on arm64.
 495
 496_GLK   6.5.7           This object requires a global lock be defined; there
 497                       is no global lock on arm64 since it runs in hardware
 498                       reduced mode.  Hence, do not use this object on arm64.
 499
 500\_GPE  5.3.1           This namespace is for x86 use only.  Do not use it
 501                       on arm64.
 502
 503_HID   6.1.5           This is the primary object to use in device probing,
 504                       though _CID and _CLS may also be used.
 505
 506_INI   6.5.1           Not required, but can be useful in setting up devices
 507                       when UEFI leaves them in a state that may not be what
 508                       the driver expects before it starts probing.
 509
 510_LPI   8.4.4.3         Recommended for use with processor definitions (_HID
 511                       ACPI0010) on arm64.  See also _RDI.
 512
 513_MLS   6.1.7           Highly recommended for use in internationalization.
 514
 515_OFF   7.2.2           It is recommended to define this method for any device
 516                       that can be turned on or off.
 517
 518_ON    7.2.3           It is recommended to define this method for any device
 519                       that can be turned on or off.
 520
 521\_OS   5.7.3           This method will return "Linux" by default (this is
 522                       the value of the macro ACPI_OS_NAME on Linux).  The
 523                       command line parameter acpi_os=<string> can be used
 524                       to set it to some other value.
 525
 526_OSC   6.2.11          This method can be a global method in ACPI (i.e.,
 527                       \_SB._OSC), or it may be associated with a specific
 528                       device (e.g., \_SB.DEV0._OSC), or both.  When used
 529                       as a global method, only capabilities published in
 530                       the ACPI specification are allowed.  When used as
 531                       a device-specific method, the process described for
 532                       using _DSD MUST be used to create an _OSC definition;
 533                       out-of-process use of _OSC is not allowed.  That is,
 534                       submit the device-specific _OSC usage description as
 535                       part of the kernel driver submission, get it approved
 536                       by the kernel community, then register it with the
 537                       UEFI Forum.
 538
 539\_OSI  5.7.2           Deprecated on ARM64.  As far as ACPI firmware is
 540                       concerned, _OSI is not to be used to determine what
 541                       sort of system is being used or what functionality
 542                       is provided.  The _OSC method is to be used instead.
 543
 544_PDC   8.4.1           Deprecated, do not use on arm64.
 545
 546\_PIC  5.8.1           The method should not be used.  On arm64, the only
 547                       interrupt model available is GIC.
 548
 549\_PR   5.3.1           This namespace is for x86 use only on legacy systems.
 550                       Do not use it on arm64.
 551
 552_PRT   6.2.13          Required as part of the definition of all PCI root
 553                       devices.
 554
 555_PRx   7.3.8-11        Use as needed; power management specific.  If _PR0 is
 556                       defined, _PR3 must also be defined.
 557
 558_PSx   7.3.2-5         Use as needed; power management specific.  If _PS0 is
 559                       defined, _PS3 must also be defined.  If clocks or
 560                       regulators need adjusting to be consistent with power
 561                       usage, change them in these methods.
 562
 563_RDI   8.4.4.4         Recommended for use with processor definitions (_HID
 564                       ACPI0010) on arm64.  This should only be used in
 565                       conjunction with _LPI.
 566
 567\_REV  5.7.4           Always returns the latest version of ACPI supported.
 568
 569\_SB   5.3.1           Required on arm64; all devices must be defined in this
 570                       namespace.
 571
 572_SLI   6.2.15          Use is recommended when SLIT table is in use.
 573
 574_STA   6.3.7,          It is recommended to define this method for any device
 575       7.2.4           that can be turned on or off.  See also the STAO table
 576                       that provides overrides to hide devices in virtualized
 577                       environments.
 578
 579_SRS   6.2.16          Use as needed; see also _PRS.
 580
 581_STR   6.1.10          Recommended for conveying device names to end users;
 582                       this is preferred over using _DDN.
 583
 584_SUB   6.1.9           Use as needed; _HID or _CID are preferred.
 585
 586_SUN   6.1.11          Use as needed, but recommended.
 587
 588_SWS   7.4.3           Use as needed; power management specific; this may
 589                       require specification changes for use on arm64.
 590
 591_UID   6.1.12          Recommended for distinguishing devices of the same
 592                       class; define it if at all possible.
 593===== ================ ========================================================
 594
 595
 596
 597
 598ACPI Event Model
 599----------------
 600Do not use GPE block devices; these are not supported in the hardware reduced
 601profile used by arm64.  Since there are no GPE blocks defined for use on ARM
 602platforms, ACPI events must be signaled differently.
 603
 604There are two options: GPIO-signaled interrupts (Section 5.6.5), and
 605interrupt-signaled events (Section 5.6.9).  Interrupt-signaled events are a
 606new feature in the ACPI 6.1 specification.  Either - or both - can be used
 607on a given platform, and which to use may be dependent of limitations in any
 608given SoC.  If possible, interrupt-signaled events are recommended.
 609
 610
 611ACPI Processor Control
 612----------------------
 613Section 8 of the ACPI specification changed significantly in version 6.0.
 614Processors should now be defined as Device objects with _HID ACPI0007; do
 615not use the deprecated Processor statement in ASL.  All multiprocessor systems
 616should also define a hierarchy of processors, done with Processor Container
 617Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator
 618devices (Section 8.5) to describe processor topology.  Section 8.4 of the
 619specification describes the semantics of these object definitions and how
 620they interrelate.
 621
 622Most importantly, the processor hierarchy defined also defines the low power
 623idle states that are available to the platform, along with the rules for
 624determining which processors can be turned on or off and the circumstances
 625that control that.  Without this information, the processors will run in
 626whatever power state they were left in by UEFI.
 627
 628Note too, that the processor Device objects defined and the entries in the
 629MADT for GICs are expected to be in synchronization.  The _UID of the Device
 630object must correspond to processor IDs used in the MADT.
 631
 632It is recommended that CPPC (8.4.5) be used as the primary model for processor
 633performance control on arm64.  C-states and P-states may become available at
 634some point in the future, but most current design work appears to favor CPPC.
 635
 636Further, it is essential that the ARMv8 SoC provide a fully functional
 637implementation of PSCI; this will be the only mechanism supported by ACPI
 638to control CPU power state.  Booting of secondary CPUs using the ACPI
 639parking protocol is possible, but discouraged, since only PSCI is supported
 640for ARM servers.
 641
 642
 643ACPI System Address Map Interfaces
 644----------------------------------
 645In Section 15 of the ACPI specification, several methods are mentioned as
 646possible mechanisms for conveying memory resource information to the kernel.
 647For arm64, we will only support UEFI for booting with ACPI, hence the UEFI
 648GetMemoryMap() boot service is the only mechanism that will be used.
 649
 650
 651ACPI Platform Error Interfaces (APEI)
 652-------------------------------------
 653The APEI tables supported are described above.
 654
 655APEI requires the equivalent of an SCI and an NMI on ARMv8.  The SCI is used
 656to notify the OSPM of errors that have occurred but can be corrected and the
 657system can continue correct operation, even if possibly degraded.  The NMI is
 658used to indicate fatal errors that cannot be corrected, and require immediate
 659attention.
 660
 661Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
 662these slightly differently.  The SCI is handled as a high priority interrupt;
 663given that these are corrected (or correctable) errors being reported, this
 664is sufficient.  The NMI is emulated as the highest priority interrupt
 665possible.  This implies some caution must be used since there could be
 666interrupts at higher privilege levels or even interrupts at the same priority
 667as the emulated NMI.  In Linux, this should not be the case but one should
 668be aware it could happen.
 669
 670
 671ACPI Objects Not Supported on ARM64
 672-----------------------------------
 673While this may change in the future, there are several classes of objects
 674that can be defined, but are not currently of general interest to ARM servers.
 675Some of these objects have x86 equivalents, and may actually make sense in ARM
 676servers.  However, there is either no hardware available at present, or there
 677may not even be a non-ARM implementation yet.  Hence, they are not currently
 678supported.
 679
 680The following classes of objects are not supported:
 681
 682       -  Section 9.2: ambient light sensor devices
 683
 684       -  Section 9.3: battery devices
 685
 686       -  Section 9.4: lids (e.g., laptop lids)
 687
 688       -  Section 9.8.2: IDE controllers
 689
 690       -  Section 9.9: floppy controllers
 691
 692       -  Section 9.10: GPE block devices
 693
 694       -  Section 9.15: PC/AT RTC/CMOS devices
 695
 696       -  Section 9.16: user presence detection devices
 697
 698       -  Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT
 699
 700       -  Section 9.18: time and alarm devices (see 9.15)
 701
 702       -  Section 10: power source and power meter devices
 703
 704       -  Section 11: thermal management
 705
 706       -  Section 12: embedded controllers interface
 707
 708       -  Section 13: SMBus interfaces
 709
 710
 711This also means that there is no support for the following objects:
 712
 713====   =========================== ====   ==========
 714Name   Section                     Name   Section
 715====   =========================== ====   ==========
 716_ALC   9.3.4                       _FDM   9.10.3
 717_ALI   9.3.2                       _FIX   6.2.7
 718_ALP   9.3.6                       _GAI   10.4.5
 719_ALR   9.3.5                       _GHL   10.4.7
 720_ALT   9.3.3                       _GTM   9.9.2.1.1
 721_BCT   10.2.2.10                   _LID   9.5.1
 722_BDN   6.5.3                       _PAI   10.4.4
 723_BIF   10.2.2.1                    _PCL   10.3.2
 724_BIX   10.2.2.1                    _PIF   10.3.3
 725_BLT   9.2.3                       _PMC   10.4.1
 726_BMA   10.2.2.4                    _PMD   10.4.8
 727_BMC   10.2.2.12                   _PMM   10.4.3
 728_BMD   10.2.2.11                   _PRL   10.3.4
 729_BMS   10.2.2.5                    _PSR   10.3.1
 730_BST   10.2.2.6                    _PTP   10.4.2
 731_BTH   10.2.2.7                    _SBS   10.1.3
 732_BTM   10.2.2.9                    _SHL   10.4.6
 733_BTP   10.2.2.8                    _STM   9.9.2.1.1
 734_DCK   6.5.2                       _UPD   9.16.1
 735_EC    12.12                       _UPP   9.16.2
 736_FDE   9.10.1                      _WPC   10.5.2
 737_FDI   9.10.2                      _WPP   10.5.3
 738====   =========================== ====   ==========
 739