Advanced Configuration and Power Interface (ACPI) Specification

https://uefi.org/htmlspecs/ACPI_Spec_6_4_html
Admin
The Advanced Configuration and Power Interface (ACPI) Specification defines a common interface for...
Tokens:456,543
Snippets:3,061
Trust Score:9.4
Update:8 months ago
Show doc for...
Tokens:
Raw
### ACPI Match Function Syntax and Examples

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference

Demonstrates the syntax and usage of the ACPI Match function for searching within a package. It shows how to define a package and then use Match with different operators and starting indices to find specific elements.

```ACPI
Name (P1,
Package () {1981, 1983, 1985, 1987, 1989, 1990, 1991, 1993, 1995, 1997, 1999, 2001}
)

// match 1993 == P1[i]
Match (P1, MEQ, 1993, MTR, 0, 0) // -> 7, since P1[7] == 1993

// match 1984 == P1[i]
Match (P1, MEQ, 1984, MTR, 0, 0) // -> ONES (not found)

// match P1[i] > 1984 and P1[i] <= 2000
Match (P1, MGT, 1984, MLE, 2000, 0) // -> 2, since P1[2]>1984 and P1[2]<=2000

// match P1[i] > 1984 and P1[i] <= 2000, starting with 3rd element
Match (P1, MGT, 1984, MLE, 2000, 3) // -> 3, first match at or past Start

```

--------------------------------

### ACPI _UPC Implementation Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/09_ACPI-Defined_Devices_and_Device-Specific_Objects/ACPIdefined_Devices_and_DeviceSpecificObjects

An example of how the _UPC object might be implemented for a USB host controller's root hub. This demonstrates the definition of devices and ports with their respective addresses and capabilities.

```ACPI ASL
//
// Root hub device for this host controller.
// This controller implements 3 root hub ports.
//
Device( RHUB) {
   Name( \_ADR, 0x00000000)         // Value of 0 is reserved for root HUB
   //
   // Root hub, port 1
   //
   Device( PRT1) {
      // Address object for port 1. This value must be 1.
      Name( \_ADR, 0x00000001)
      // USB port capabilities object. This object returns the system

```

--------------------------------

### ACPI S4 Sleeping State Implementation Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index

This snippet provides an example of implementing the S4 sleeping state (hibernate) in ACPI. It covers both OS-initiated and BIOS-initiated transitions to and from the S4 state.

```ASL
Method (S4_OS_INITIATED)
{
  // OS-initiated S4 transition logic
  Sleep (S4)
}

Method (S4_BIOS_TRANSITION)
{
  // BIOS-initiated S4 transition logic
}
```

--------------------------------

### ACPI _EVT Method Example (ACPI ASL)

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model

This example demonstrates the structure and usage of the _EVT method within an ACPI scope. It shows how to handle different GPIO-signaled events using a Switch statement and trigger notifications for specific devices.

```ACPI ASL
Scope (\_SB.GPI2)
{
  Method (_EVT,1) { // Handle all ACPI Events signaled by GPIO Controller GPI2
    Switch (Arg0)
    {
      Case (300) {
        ...
        Notify (\_SB.DEVX, 0x80)
      }
      Case (1801) {
        ...
        Notify (\_SB.DEVY, 0x80)
      }
      Case (14…) {
        ...
        Notify (\_SB.DEVZ, 0x80)
      }
      ...
    }
  } //End of Method
} //End of Scope

```

--------------------------------

### ACPI Namespace Path Examples

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model

Illustrates different types of ACPI namespace paths and whether standard search rules apply. These examples are crucial for understanding how the ACPI system resolves object references within its hierarchical namespace.

```ASL
ABCD        //search rules apply
^ABCD       //search rules do not apply
XYZ.ABCD    //search rules do not apply
\XYZ.ABCD  //search rules do not apply
```

--------------------------------

### ACPI _DSM Method Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/09_ACPI-Defined_Devices_and_Device-Specific_Objects/ACPIdefined_Devices_and_DeviceSpecificObjects

An example implementation of the _DSM (Device Specific Method) in ACPI. This code demonstrates how to handle different UUIDs, revision IDs, and function indices, including the special function index 0 for querying supported functions.

```ACPI ASL
Function(_DSM,{IntObj,BuffObj},{BuffObj, IntObj, IntObj, PkgObj})
{
   //
   // Switch based on which unique function identifier was passed in
   //
  switch(Arg0)
  {
   //
   // First function identifier
   //
  case(ToUUID("893f00a6-660c-494e-bcfd-3043f4fb67c0"))
  {
   switch(Arg2)
   {
    //
    // Function 0: Return supported functions, based on revision
    //
    case(0)
    {
    switch(Arg1)
    {
     // revision 0: functions 1-4 are supported
     case(0) {return (Buffer() {0x1F})}
     // revision 1: functions 1-5 are supported
     case(1) {return (Buffer() {0x3F})}
    }
    // revision 2+: functions 1-7 are supported
    return (Buffer() {0xFF})
   }
   //
   // Function 1:
   //
   case(1)
   {
    ... function 1 code ...
    Return(Zero)
   }
   //
   // Function 2:
   //
   case(2)
   {
    ... function 2 code ...
    Return(Buffer(){0x00})
   }
   case(3) { ... function 3 code ...}
   case(4) { ... function 4 code ...}
   case(5) { if (LLess(Arg1,1) BreakPoint; ... function 5 code ... }
   case(6) { if (LLess(Arg1,2) BreakPoint; ... function 6 code ... )
   case(7) { if (LLess(Arg1,3) BreakPoint; ... function 7 code ... )
   default {BreakPoint }
  }
 }
 //
 // Second function identifier
 //
 case(ToUUID("107ededd-d381-4fd7-8da9-08e9a6c79644"))
 {
  //
  // Function 0: Return supported functions (there is only one revision)
  //
  if (LEqual(Arg2,Zero))
    return (Buffer() {0x3}) // only one function supported
  //
  // Function 1
  //
  if (LEqual(Arg2,One))
  {
   ... function 1 code ...
   Return(Unicode("text"))
   }
   //
   // Function 2+: Runtime Error
   //
    else
     BreakPoint;
   }
  }
  //
  // If not one of the UUIDs we recognize, then return a buffer

```

--------------------------------

### ACPI S3 Sleeping State Implementation Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index

This snippet provides an example of implementing the S3 sleeping state in ACPI. It outlines the necessary ACPI Source Language (ASL) code to manage the transition to and from the S3 state.

```ASL
Method (S3_ENTRY)
{
  // Code to prepare for S3 sleep
  Sleep (S3)
  // Code to wake from S3 sleep
}

Method (S3_EXIT)
{
  // Code to handle wake events from S3
}
```

--------------------------------

### ACPI _DSD Example: Basic Device Properties

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration

Illustrates the basic usage of the _DSD object to provide device-specific properties. This example assumes a UUID that defines the data structure as a list of key-value pairs.

```ACPI ASL
Device (MDEV) {
Name (_HID, "PNP####")

Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package (2) {...}, // Property 1
            ...
            Package (2) {...} // Property n
        }
    })
}
```

--------------------------------

### ACPI S1 Sleeping State Implementation Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index

This snippet provides an example of implementing the S1 sleeping state in ACPI. It outlines the necessary ACPI Source Language (ASL) code to manage the transition to and from the S1 state.

```ASL
Method (S1_ENTRY)
{
  // Code to prepare for S1 sleep
  Sleep (S1)
  // Code to wake from S1 sleep
}

Method (S1_EXIT)
{
  // Code to handle wake events from S1
}
```

--------------------------------

### ACPI S2 Sleeping State Implementation Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index

This snippet provides an example of implementing the S2 sleeping state in ACPI. It outlines the necessary ACPI Source Language (ASL) code to manage the transition to and from the S2 state.

```ASL
Method (S2_ENTRY)
{
  // Code to prepare for S2 sleep
  Sleep (S2)
  // Code to wake from S2 sleep
}

Method (S2_EXIT)
{
  // Code to handle wake events from S2
}
```

--------------------------------

### ACPI Object Creation Examples

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model

Demonstrates how to create new ACPI objects using namepaths. This includes defining a device and an operation region, highlighting the requirement for parent objects to exist prior to child object creation.

```ASL
Device (XYZ.ABCD) {...}
OperationRegion (\XYZ.ABCD, SystemMemory, 0, 0x200)
```

--------------------------------

### ASL Example Code Corrections in ACPI 5.1

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/Frontmatter/Revision_History

This snippet addresses issues found in the ASL (ACPI Source Language) example code within the ACPI 5.1 specification. It specifically points out a bug in the example for the _OSC method and invalid keywords in the example for _REG.

```ASL
/* Bug in ASL example code for _OSC method */
// Section 6.2.10.4

/* Invalid AddressSpaced keywords in example ASL code, orphan _REG */
// Section 6.5.4
```

--------------------------------

### Interrupt Resource Example (ACPI ASL)

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference

An example demonstrating the usage of the Interrupt macro within a ResourceTemplate. This specific example shows how a device (SDC0) consumes a secondary interrupt from an interrupt producer device (MUX0), illustrating the ResourceConsumer, Level, ActiveHigh, and Exclusive arguments.

```asl
Scope(_SB) {

  Device(MUX0){
    Name(_HID, EISAID("ACME0F0F")) // vendor specific interrupt combiner
    Name(_UID, 0)
    Name(_CRS, ResourceTemplate () {
      //Register Interface
      MEMORY32FIXED(ReadWrite, 0x30000000, 0x200, )
      //Summary Interrupt line (GSIV 51)
      Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) {51}
    })
  }

  Device(SDC0){

```

--------------------------------

### _NCH (Get NVDIMM Current Health Information)

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/09_ACPI-Defined_Devices_and_Device-Specific_Objects/ACPIdefined_Devices_and_DeviceSpecificObjects

This method provides current health information of the NVDIMM device. OSPM can call this method at any time to get the current health of the NVDIMM device.

```APIDOC
## _NCH (Get NVDIMM Current Health Information)

### Description
This method provides current health information of the NVDIMM device. The platform notifies OSPM by NVDIMM Device NFIT Health Event Notification whenever anything happens that can impact health of NVDIMM device. When OSPM receives the notification, it can get the current health information by calling this method. Regardless of health notification, OSPM can call this method at any time to get the current health of the NVDIMM device.

### Method
GET (or equivalent for ACPI method invocation)

### Endpoint
Not applicable (ACPI method)

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body
None

### Request Example
None

### Response
#### Success Response
A buffer containing the current health information as described below:

**Return Value Information:**
| Field                       | Byte Length | Byte Offset | Description
```

--------------------------------

### ASL Example: Creating a Resource Template for _PRS Method

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference

Demonstrates the usage of ResourceTemplate and various resource descriptor macros (StartDependentFn, IRQ, DMA, IO) to construct a resource template suitable for returning from an ASL _PRS control method.

```asl
Name (PRS0, ResourceTemplate ()
{
   StartDependentFn (1, 1)
   {
      IRQ (Level, ActiveLow, Shared) {10, 11}
      DMA (TypeF, NotBusMaster, Transfer16) {4}
      IO (Decode16, 0x1000, 0x2000, 0, 0x100)
      IO (Decode16, 0x5000, 0x6000, 0, 0x100, IO1)
   }
   StartDependentFn (1, 1)
   {
      IRQ (Level, ActiveLow, Shared) {}
      DMA (TypeF, NotBusMaster, Transfer16){5}
      IO (Decode16, 0x3000, 0x4000, 0, 0x100)
      IO (Decode16, 0x5000, 0x6000, 0, 0x100, IO2)
   }
   EndDependentFn ()
})
```

--------------------------------

### ACPI _CBR Method Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration

An example of the _CBR control method within an ACPI Device declaration. This method returns the CXL Host Bridge Register Information, including version, base address, and length.

```ACPI
Device(CXL0 ) {
   Name(_HID, EISAID ("ACPI0016")) // New HID to indicate CXL hierarchy
   Name(_CID, EISAID ("PNP0A08"))  // To support legacy OSs that understands PCIe
                                   // but not the new HID
   Name(_UID, 0)
   Method (_CBR, 0) {
       Return( 0x00, DP_RCRB_BASE, 0x2000)
   }
   // Standard PCIe methods like _ BBN, _CRS.
   // PCIe _CRS describes .IO resources. PCIe _BBN describes bus number of CXL RCiEP
   // PCIe _OSC is used to negotiate control of CXL.IO capabilities
   ...
}
```

--------------------------------

### Example ACPI Resource Template with IO and IRQ

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference

An example demonstrating the usage of IO and IRQ macros within a ResourceTemplate in ACPI ASL. This snippet shows how to define memory, I/O, and interrupt resources for a device.

```ACPI ASL
Name(_HID, EISAID("PNP0D40")) // SDA Standard Compliant SD Host Controller
    Name(_UID, 0)
    Name(_CRS, ResourceTemplate() {
      //Register Interface
      MEMORY32FIXED(ReadWrite, 0xFF000000, 0x200, )
      // Secondary Interrupt 10 from interrupt combiner MUX0
      Interrupt(ResourceConsumer, Edge, ActiveHigh, Exclusive, 0, "\\_SB.MUX0"){
        10
      }
      }
    )
  }
}
```

--------------------------------

### ASL Start Dependent Function (Terminated)

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference

Defines a Start Dependent Function with compatibility and performance priority. This term is followed by a ResourceMacroList, indicating the resources associated with this function.

```ASL
StartDependentFnTerm :=

StartDependentFn (
CompatPriority, // ByteConstExpr (0-2)
PerfRobustPriority // ByteConstExpr (0-2)
) {ResourceMacroList}

```

--------------------------------

### _GTF Method and Example Return Value (ACPI ASL)

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/09_ACPI-Defined_Devices_and_Device-Specific_Objects/ACPIdefined_Devices_and_DeviceSpecificObjects

This snippet shows the ACPI ASL definition for the _GTF method and an example of the 'GTF0' buffer it returns. The buffer contains a sequence of ATA task file register values used to configure the drive.

```ACPI ASL
Method(_GTF, 0x0, NotSerialized)
{
   Return(GTF0)
}
Name(GTF0, Buffer(0x1c)
{
   0x03, 0x00, 0x00, 0x00, 0x00, 0xa0, 0xef, 0x03, 0x00, 0x00, 0x00, 0x00,
   0xa0, 0xef, 0x00, 0x10, 0x00, 0x00, 0x00, 0xa0, 0xc6, 0x00, 0x00, 0x00,
   0x00, 0x00, 0xa0, 0x91
}

```

--------------------------------

### ACPI AML: Basic Resource Template Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference

A basic ACPI AML resource template example showing memory and interrupt resource definitions within a ResourceTemplate block.

```acpi
   Name (RBUF, ResourceTemplate()
   {
      Memory32Fixed(ReadWrite, 0x4FE00000, 0x20)
      Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) {0x54}
      PinGroup("group1", ResourceProducer) {2, 3}
   })
   Return(RBUF)
```

--------------------------------

### ACPI _DSD Example: PWM Controller Configuration

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration

Demonstrates how to use _DSD to configure a PWM controller. It specifies the number of PWM cells required for the device, indicating how to control its output.

```ACPI ASL
Device (\_SB.PCI0.PWM) {
    Name (_HID, "PNP####")

    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package (2) {"#pwm-cells", 2}
        }
    })
}
```

--------------------------------

### ACPI _MLS Object Definition and Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration

Defines the structure and usage of the _MLS object, which returns a package of language descriptor packages. Each descriptor contains a LanguageId and a UnicodeDescription. The example demonstrates its implementation within a Device object.

```ASL
Package {
   LanguageDescriptor[0] // Package
   LanguageDescriptor[n] // Package
}

Package {
   LanguageId // String
   UnicodeDescription // Buffer
}

Device (XYZ) {
   Name (_ADR, 0x00020001)
   Name ( \_MLS, Package(){(2){"en", Unicode("ACME super DVD controller")}})
}
```

--------------------------------

### GeneralPurposeIO Operation and Field Declaration Example - ASL

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model

An ASL code example demonstrating the declaration and usage of GeneralPurposeIO Operation Regions and Fields. It includes device scopes, resource templates, field definitions for controlling device power modes and status, and a method to set the power mode.

```ASL
Device(DEVA) //An Arbitrary Device Scope
{
    // Other required stuff for this device
    Name (GMOD, ResourceTemplate () 
      //An existing GPIO Connection (to be used later)
    )
    {
        //2 Outputs that define the Power mode of the device
        GpioIo (Exclusive, PullDown, , , , "\_SB.GPI2") {10, 12}
    }
} //End DEVA

Device (GPI2) //The OpRegion declaration, and the \_REG method,
              //must be in the controller's namespace scope
{
    //Other required stuff for the GPIO controller
    OperationRegion(GPO2, GeneralPurposeIO, 0, 1)
        // Note: length of 1 means region is less than 1 byte (8 pins) long
    Method(_REG,2)
    {
        // Track availability of GeneralPurposeIO space
    }
}

Device (DEVB) //Access some GPIO Pins from this device scope
              //to change the device's power mode
{
    //.. Other required stuff for this device

    Name(_DEP, Package() {"\_SB.GPI2"}) //OpRegion Dependency hint for OSPM
    Field(\_SB.GPI2.GPO2, ByteAcc, NoLock, Preserve)
    {
        Connection (GMOD), // Re-Use an existing connection (defined elsewhere)
        MODE, 2,           // Power Mode
        Connection (GpioIo(Exclusive, PullUp, , , , "\_SB.GPI2") {7}),
        STAT, 1,           // e.g. Status signal from the device
        Connection (GpioIo (Exclusive, PullUp, , , , "\_SB.GPI2") {9}),
        RSET, 1            // e.g. Reset signal to the device
    }

    Method(_PS3)
    {
        If (1)            // Make sure GeneralPurposeIO OpRegion is available
        {
            MODE = 0x03   //Set both MODE bits. Power Mode 3
        }
    }
} //End DEVB

```

--------------------------------

### ASL Definition Block Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model

An example of an ACPI Source Language (ASL) definition block, demonstrating the structure for defining hardware control methods and resources. This code is typically translated into a byte stream encoding for ACPI tables.

```ASL
DefinitionBlock (
 "forbook.aml",                    // Output Filename
 "DSDT",                           // Signature
 0x02,                             // DSDT Compliance Revision
 "OEM",                            // OEMID
 "forbook",                        // TABLE ID
 0x1000                            // OEM Revision
)
{
     OperationRegion(\/GIO, SystemIO, 0x125, 0x1)
     Field(\/GIO, ByteAcc, NoLock, Preserve)
     {
         CT01, 1,
     }

     Scope(\_SB)
     {
         Device(PCI0)
         {
             PowerResource(FET0, 0, 0)
             {
                 Method (_ON)
                 {
                     CT01 = Ones   // assert power
                     Sleep (30)    // wait 30ms
                 }

                 Method (_OFF)
                 {
                     CT01 = Zero   // assert reset#
                 }

                 Method (_STA)
                 {
                     Return (CT01)
                 }
             }
         }
     }
}

```

--------------------------------

### ASL Definition Block Loading Example

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model

This ASL code demonstrates the structure of a Definition Block, including its header and the dynamic definition of objects based on configuration checks. It shows how nested scopes and devices can be conditionally created.

```asl
DefinitionBlock ("DSDT.aml", "DSDT", 2, "OEM", "FOOBOOK", 0x1000)
{
    ...
    If (CFG1 () == 1))
    {
        ...
        Scope (_SB.PCI0.XHC.RHUB)
        {
            ...
            If (CFG2 () == 1)
            {
                ...
                Device (HS11)
                {
                    ...
                    If (CFG3 () == 1)
                    {
                        ...
                        Device (CAM0)
                        {
                        ...
                        }
                        ...
                    }
                    ...
                }
                ...
            }
            ...
        }
        ...
    }
    ...
}

```

--------------------------------

### _HPX Method Documentation

Source: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration

Details the _HPX method, its arguments, return value, and its interaction with OSPM for managing hot-plugged PCI devices.

```APIDOC
## _HPX (Hot Plug Parameter Extensions)

### Description
This optional object provides platform-specific information to the OSPM PCI driver component responsible for configuring PCI, PCI-X, or PCI Express Functions. The information conveyed applies to the entire hierarchy downward from the scope containing the _HPX object. If another _HPX object is encountered downstream, the settings conveyed by the lower-level object apply to that scope downward.

OSPM uses the information returned by _HPX to determine how to configure PCI Functions that are hot-plugged into the system, to configure Functions not configured by the platform firmware during initial system boot, and to configure Functions any time they lose configuration space settings (e.g. OSPM issues a Secondary Bus Reset/Function Level Reset or Downstream Port Containment is triggered). The _HPX object is placed within the scope of a PCI-compatible bus where this behavior is desired, such as a bus with hot-plug slots. It returns a single package that contains one or more sub-packages, each containing a single Setting Record. Each such Setting Record contains a Setting Type (INTEGER), a Revision number (INTEGER) and type/revision specific contents.

The format of data returned by the _HPX object is extensible. The Setting Type and Revision number determine the format of the Setting Record. OSPM ignores Setting Records of types that it does not understand. A Setting Record with higher Revision number supersedes that with lower revision number, however, the _HPX method can return both together, OSPM shall use the one with highest revision number that it understands. Type 3 records may have multiple records with the same revision or different revision (refer to the Revision field in PCI Express Descriptor Setting Record Content. Out of all the Type 3 records, the OSPM shall determine the highest revision number that it understands and use all Type 3 records with that revision.

_HPX may return multiple types or Record Settings (each setting in a single sub-package.) OSPM is responsible for detecting the type of Function and for applying the appropriate settings. OSPM is also responsible for detecting the device / port type of the PCI Express Function and applying the appropriate settings provided. For example, the Secondary Uncorrectable Error Severity and Secondary Uncorrectable Error Mask settings of Type 2 record are only applicable to PCI Express to PCI-X/PCI Bridge whose device / port type is 1000b. Similarly, AER settings are only applicable to hot plug PCI Express devices that support the optional AER capability.

### Method
ACPI Control Method

### Endpoint
Not applicable (This is an ACPI method, not a REST API endpoint)

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body
None

### Request Example
```acpi
_HPX()
```

### Response
#### Success Response
- **Package** (Package) - A variable-length Package containing a list of Packages, each containing a single PCI, PCI-X, PCI Express, or PCI Express Descriptor Record Setting.

#### Response Example
```acpi
Package() {
  Package() { /* Setting Record 1 */ }
  Package() { /* Setting Record 2 */ }
  // ... more Setting Records
}
```

### Notes
- The _HPX object supersedes the _HPP object. If both exist within a device’s scope, OSPM will only evaluate the _HPX object.
- OSPM may override settings from Type 2 or Type 3 records if OSPM has assumed native control of the corresponding feature (e.g., AER via _OSC).
- OSPM is not required to clear error status registers as part of _HPX handling.
- System firmware should provide platform-specific information via only one mechanism (e.g., _HPX or _DSM for Latency Tolerance Reporting) to avoid undefined behavior.
```
Tokens:
Raw