ACPI (Advanced Configuration and Power Interface)

ACPI: 아키텍처 4계층, 네임스페이스(Namespace), FADT/MADT/DMAR/HMAT/BERT 테이블, G/S/D-state 전원 관리(Power Management), 열 관리(Thermal Management), GPE/SCI, Embedded Controller, Operation Region, 핫플러그(Hotplug), 커널 ACPI 서브시스템, 디버깅(Debugging)

ACPI 아키텍처 4계층, 네임스페이스, 주요 테이블, 전원 상태 계층(G/S/D), 열 관리, GPE/SCI, Embedded Controller, Operation Region, 핫플러그, 커널 ACPI 서브시스템까지 — 리눅스 커널의 ACPI 구현을 소스 코드 수준에서 분석합니다.

ACPI 아키텍처 개요

ACPI(Advanced Configuration and Power Interface)는 OS가 하드웨어 구성 탐색, 전원 관리, 열 관리를 수행하기 위한 플랫폼 독립적 인터페이스 규격입니다. 1996년 Intel/Microsoft/Toshiba가 공동 개발했으며, 2013년부터 UEFI Forum이 관리합니다.

스펙 버전 역사

4대 구성요소

ACPI 규격은 네 가지 핵심 구성요소로 이루어집니다:

1. ACPI Tables — RSDP → XSDT → {FADT, MADT, DMAR, HMAT, ...} 계층 구조의 정적 데이터 테이블. 펌웨어가 메모리에 배치합니다.
2. ACPI Namespace — 디바이스, 메서드, 오브젝트를 트리 구조로 조직하는 계층적 이름 공간. AML 코드가 정의합니다.
3. AML Interpreter — DSDT/SSDT의 AML 바이트코드를 실행하는 커널 내 인터프리터. 리눅스는 ACPICA(ACPI Component Architecture) 코드를 사용합니다.
4. ACPI Event Model — SCI(System Control Interrupt)와 GPE(General Purpose Event)를 통한 비동기 하드웨어 이벤트 처리.

RSDP에서 네임스페이스까지

부팅 초기에 커널은 먼저 ACPI의 "입구"를 찾아야 합니다. UEFI 환경에서는 EFI Configuration Table을 통해 RSDP를 얻고, 전통적인 x86 환경에서는 EBDA 또는 BIOS 고메모리 영역을 스캔해 RSDP 시그니처를 찾습니다. 이후 RSDP가 가리키는 XSDT/RSDT를 검증한 뒤, FADT와 DSDT/SSDT를 로드해 네임스페이스와 실행 메서드를 준비합니다.

AML (ACPI Machine Language)

AML(ACPI Machine Language)은 ASL(ACPI Source Language)을 컴파일한 바이트코드입니다. 펌웨어 벤더가 ASL로 하드웨어 제어 로직을 작성하면, iasl 컴파일러가 이를 AML 바이트코드로 변환하고, DSDT/SSDT 테이블 안에 저장합니다. 커널의 ACPICA 인터프리터는 부팅 시 이 AML을 파싱·실행하여 네임스페이스를 구축하고, 런타임에도 메서드 호출 시마다 AML을 해석합니다.

AML은 스택 기반 바이트코드로, 약 200여 개의 오퍼코드를 정의합니다. 아래 표는 DSDT/SSDT에서 가장 빈번히 등장하는 핵심 오퍼코드입니다:

아래는 실제 DSDT에서 매우 흔하게 발견되는 ASL 패턴입니다. _STA 메서드는 OS 버전에 따라 디바이스 존재 여부를 결정합니다:

// _STA: 디바이스 상태 반환 (0x0F = Present + Enabled + Functioning)
Method (_STA, 0, NotSerialized)
{
    If (LEqual (OSYS, 0x07DF))  // Windows 2015 (= Windows 10)
    {
        Return (0x0F)  // 디바이스 존재 + 활성 + 기능 + UI 표시
    }
    Else
    {
        Return (Zero)  // 디바이스를 숨김
    }
}

// _STA 반환 비트 의미
// Bit 0: Present (하드웨어 존재)
// Bit 1: Enabled (기능 활성)
// Bit 2: Show in UI (장치 관리자 표시)
// Bit 3: Functioning (정상 동작)
// Bit 4: Battery Present (배터리 전용)

ACPI 부팅 초기화 시퀀스

커널의 ACPI 초기화는 부팅 과정(Boot Process) 전반에 걸쳐 여러 단계로 나뉩니다. 아래 다이어그램은 RSDP 탐색부터 드라이버 매칭까지의 전체 흐름을 보여줍니다:

아래는 실제 커널 부팅 로그에서 볼 수 있는 ACPI 초기화 타임라인입니다. 각 행의 타임스탬프로 단계별 소요 시간을 추적할 수 있습니다:

[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F05B0 000024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 0x000000007A7FE098 0000EC (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x000000007A7FD000 000114 (v06 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x000000007A7E4000 018C5A (v02 ALASKA A M I    01072009 INTL 20200925)
[    0.000000] ACPI: MADT 0x000000007A7FC000 0000BC (v05 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: MCFG 0x000000007A7FB000 00003C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: DMAR 0x000000007A7F5000 000088 (v02 ALASKA A M I    01072009 AMI  00010013)
[    0.052813] ACPI: Added _OSI(Module Device)
[    0.052815] ACPI: Added _OSI(Processor Device)
[    0.052816] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.052818] ACPI: Added _OSI(Processor Aggregator Device)
[    0.167492] ACPI: Interpreter enabled
[    0.167776] ACPI: Using IOAPIC for interrupt routing
[    0.168012] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.169243] ACPI: PCI Root [\_SB_.PCI0]
[    0.170510] ACPI: \_SB_.PCI0: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]

ACPICA 내부 구조

ACPICA(ACPI Component Architecture)는 Intel이 유지보수하는 OS 독립적 ACPI 참조 구현체로, 리눅스 커널에서는 drivers/acpi/acpica/ 디렉토리에 위치합니다. 약 100개 이상의 소스 파일로 구성되며, 파일 접두사로 서브시스템을 구분합니다:

# ACPICA 서브시스템별 파일 수 확인
ls drivers/acpi/acpica/ds*.c | wc -l   # Dispatcher: ~15개
ls drivers/acpi/acpica/ex*.c | wc -l   # Executer: ~20개
ls drivers/acpi/acpica/ps*.c | wc -l   # Parser: ~10개
ls drivers/acpi/acpica/ns*.c | wc -l   # Namespace: ~15개
ls drivers/acpi/acpica/ev*.c | wc -l   # Events: ~12개

# AML 해석 흐름 추적 (simplified)
# ps_parse_aml() → ds_call_control_method() → ex_opcode_*() → ns_lookup()

ACPI 네임스페이스

ACPI 네임스페이스는 역 트리(inverted tree) 구조로, 루트 스코프(\) 아래에 모든 ACPI 오브젝트가 계층적으로 배치됩니다. DSDT/SSDT의 ASL 코드가 네임스페이스를 정의하며, 커널의 ACPICA 인터프리터가 이를 파싱하여 내부 트리로 구축합니다.

루트 스코프 트리

디바이스 열거 흐름

커널 부팅 시 ACPI 서브시스템은 네임스페이스를 순회하며 모든 디바이스를 열거합니다:

/* drivers/acpi/scan.c — ACPI 디바이스 열거 핵심 흐름 */

/* 1단계: 네임스페이스 순회 — 각 노드마다 콜백 호출 */
int acpi_bus_scan(acpi_handle handle)
{
    /* 루트부터 DFS(깊이 우선)로 네임스페이스 순회 */
    acpi_walk_namespace(ACPI_TYPE_ANY, handle,
                        ACPI_UINT32_MAX,
                        acpi_bus_check_add,  /* descending */
                        acpi_bus_attach,     /* ascending  */
                        NULL, (void **)&device);
    return 0;
}

/* 2단계: acpi_device 생성 */
static acpi_status acpi_bus_check_add(acpi_handle handle, ...)
{
    /* _STA 메서드 평가 — 디바이스 존재/활성 확인 */
    acpi_bus_get_status(device);

    /* _HID/_CID 평가 — 하드웨어 ID 추출 */
    acpi_device_add(device, ...);
}

/* 3단계: 드라이버 매칭 — acpi_device_id 테이블 비교 */
static void acpi_bus_attach(struct acpi_device *device)
{
    /* ACPI 드라이버 또는 platform_device로 바인딩 */
    device_attach(&device->dev);
}

핵심 오브젝트: 식별, 자원, 속성

네임스페이스의 모든 노드가 동일하게 취급되지는 않습니다. Linux는 _HID, _CID, _ADR, _STA, _CRS 같은 표준 오브젝트를 우선 읽어 열거 여부와 자원 배치를 결정합니다. 반대로 PCI나 USB처럼 본래 자체 열거 메커니즘이 있는 버스는 ACPI가 "보조 구성 정보"를 제공하는 역할을 맡습니다.

펌웨어와 OS의 협상: _OSI, _REV, _OSC

ACPI는 단순 기술 테이블만이 아니라 펌웨어와 OS가 서로 능력을 타협하는 인터페이스도 정의합니다. 이 협상은 장치 열거보다 더 미묘한 호환성 문제를 일으키므로, 부팅 옵션과 PCIe 네이티브 제어 문제를 볼 때 특히 중요합니다.

Notify 메커니즘

ACPI Notify는 펌웨어가 OS에 비동기 이벤트를 알리는 메커니즘입니다. AML 코드에서 Notify(device, value)를 호출하면 커널의 등록된 핸들러가 실행됩니다.

네임스페이스 워킹 커널 API

커널 드라이버와 ACPI 서브시스템은 네임스페이스를 탐색하고 오브젝트를 평가하기 위해 일련의 C API를 사용합니다. 가장 핵심적인 함수는 acpi_walk_namespace(), acpi_get_handle(), acpi_evaluate_object()입니다.

acpi_walk_namespace()는 콜백 패턴으로 동작합니다. 지정한 타입에 해당하는 모든 노드를 방문하면서 콜백 함수를 호출합니다:

/* 네임스페이스 워킹 콜백 예시 — 모든 디바이스 열거 */
static acpi_status my_device_callback(acpi_handle handle,
                                       u32 level,
                                       void *context,
                                       void **return_value)
{
    struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
    acpi_status status;

    status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &buf);
    if (ACPI_SUCCESS(status)) {
        pr_info("ACPI device: %s\n", (char *)buf.pointer);
        kfree(buf.pointer);
    }

    return AE_OK;  /* AE_OK = 계속 탐색, AE_CTRL_TERMINATE = 중단 */
}

/* _SB 아래 모든 디바이스(깊이 제한 없음)를 열거 */
acpi_walk_namespace(ACPI_TYPE_DEVICE,
                    ACPI_ROOT_OBJECT,
                    ACPI_UINT32_MAX,
                    my_device_callback,
                    NULL, NULL, NULL);

특정 ACPI 경로의 오브젝트를 직접 평가하는 패턴도 자주 사용됩니다:

/* 특정 디바이스의 _STA 메서드 평가 */
acpi_status status;
acpi_handle handle;
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;

/* 1. 네임스페이스 경로로 핸들 획득 */
status = acpi_get_handle(NULL, "\\_SB.PCI0", &handle);
if (ACPI_FAILURE(status))
    return -ENODEV;

/* 2. _STA 메서드 평가 */
status = acpi_evaluate_object(handle, "_STA", NULL, &buf);
if (ACPI_SUCCESS(status)) {
    obj = (union acpi_object *)buf.pointer;
    if (obj->type == ACPI_TYPE_INTEGER)
        pr_info("_STA = 0x%llx\n", obj->integer.value);
    kfree(buf.pointer);
}

/* 간편 정수 평가 API */
unsigned long long sta_val;
status = acpi_evaluate_integer(handle, "_STA", NULL, &sta_val);
/* sta_val에 _STA 반환값이 저장됨 */

자주 등장하는 ASL 패턴

DSDT/SSDT에서 반복적으로 나타나는 핵심 ASL 패턴을 이해하면 ACPI 디버깅 시 빠르게 문제를 파악할 수 있습니다. 아래는 실제 펌웨어에서 가장 빈번히 사용되는 5가지 패턴입니다.

1. _STA (Status) — 디바이스 존재/활성 상태

모든 ACPI 디바이스의 첫 번째 관문입니다. 커널은 디바이스 열거 시 _STA를 먼저 호출해 존재 여부를 판단합니다:

// _STA 반환값 비트 마스크
// Bit 0 (0x01): Present — 하드웨어 존재
// Bit 1 (0x02): Enabled — 기능 활성
// Bit 2 (0x04): Show in UI — 장치 관리자 표시
// Bit 3 (0x08): Functioning — 정상 동작

Device (HPET)
{
    Name (_HID, EisaId ("PNP0103"))
    Method (_STA, 0, NotSerialized)
    {
        If (HPTE)       // 글로벌 변수로 HPET 활성 여부 확인
        {
            Return (0x0F)  // Present + Enabled + UI + Functioning
        }
        Return (Zero)
    }
}

2. _CRS (Current Resource Settings) — 현재 할당 자원

디바이스가 사용하는 I/O 포트, 메모리 영역, IRQ를 버퍼 형태로 기술합니다:

Method (_CRS, 0, Serialized)
{
    Name (RBUF, ResourceTemplate ()
    {
        Memory32Fixed (ReadWrite,
            0xFED00000,   // 베이스 주소
            0x00000400,   // 길이
            )
        IRQNoFlags ()
            {8}           // IRQ 8
        IO (Decode16,
            0x0060,       // 최소 포트
            0x0060,       // 최대 포트
            0x01,         // 정렬
            0x01,         // 길이
            )
    })
    Return (RBUF)
}

3. _INI (Initialize) — 부팅 초기화

디바이스 스코프에 _INI가 있으면 커널이 해당 디바이스를 열거할 때 자동 실행됩니다:

Device (EC0)
{
    Name (_HID, EisaId ("PNP0C09"))
    Method (_INI, 0, NotSerialized)
    {
        // EC 초기화 — 글로벌 변수 설정
        Store (One, ECON)      // EC 사용 가능 플래그
        Store (0x07DF, OSYS)   // OS 버전 변수
    }
}

4. _DSM (Device Specific Method) — 벤더 확장 UUID 기반 메서드

ACPI 4.0에서 도입된 범용 확장 메커니즘으로, UUID로 기능 집합을 식별합니다. 4개의 인자를 받습니다: UUID, Revision, Function Index, 함수별 인자 패키지.

Method (_DSM, 4, Serialized)
{
    // Arg0: UUID, Arg1: Revision, Arg2: Function Index, Arg3: Arguments
    If (LEqual (Arg0, ToUUID ("33DB4D5B-1FF7-401C-9657-7441C03DD766")))
    {
        Switch (ToInteger (Arg2))
        {
            Case (0)  // Function 0: Supported functions bitmask
            {
                Return (Buffer () {0x03})  // Function 0, 1 지원
            }
            Case (1)  // Function 1: Get property
            {
                Return (PROP)
            }
        }
    }

    // 알 수 없는 UUID — 빈 버퍼 반환 (미지원 표시)
    Return (Buffer () {0x00})
}

5. _DSD (Device Properties) — Device Properties UUID 기반 속성

ACPI 5.1에서 도입되었으며, Device Tree의 프로퍼티 모델과 유사한 키-값 쌍을 제공합니다:

Name (_DSD, Package ()
{
    // Device Properties UUID
    ToUUID ("DAFFD814-6EBA-4D8C-8A91-BC9BBF4AA301"),
    Package ()
    {
        Package () { "compatible", "vendor,sensor-xyz" },
        Package () { "clock-frequency", 400000 },
        Package () { "interrupt-gpios", Package ()
        {
            ^GPIO, 0, 0, 0   // GPIO 컨트롤러 참조
        }},
    }
})

주요 ACPI 테이블

ACPI는 수십 종의 테이블을 정의합니다. 여기서는 UEFI 페이지에서 다룬 테이블 계층 구조를 전제로, 각 테이블의 내부 구조와 커널 파싱 로직을 다룹니다.

FADT (Fixed ACPI Description Table)

FADT는 ACPI의 "마스터 테이블"로, PM 레지스터 주소, SCI 인터럽트 번호, FACS/DSDT 포인터, 그리고 시스템 전체의 ACPI 동작 플래그를 담습니다.

/* include/acpi/actbl.h — FADT 핵심 필드 (ACPI 6.6 기준) */
struct acpi_table_fadt {
    struct acpi_table_header header;  /* "FACP" 시그니처 */
    u32 facs;                         /* FACS 물리 주소 (32-bit) */
    u32 dsdt;                         /* DSDT 물리 주소 (32-bit) */
    u8  preferred_profile;             /* PM 프로필: Desktop/Mobile/Server */
    u16 sci_interrupt;                 /* SCI IRQ 번호 (보통 9) */
    u32 smi_command;                   /* SMI 커맨드 포트 (ACPI enable) */
    u8  acpi_enable;                   /* SMI로 보낼 ACPI 활성화 값 */
    u8  acpi_disable;                  /* SMI로 보낼 ACPI 비활성화 값 */

    /* PM1a/PM1b 레지스터 블록 */
    u32 pm1a_event_block;              /* PM1a_STS + PM1a_EN */
    u32 pm1b_event_block;              /* PM1b_STS + PM1b_EN (선택) */
    u32 pm1a_control_block;            /* SLP_TYP, SLP_EN 비트 */
    u32 pm1b_control_block;

    /* GPE 레지스터 블록 */
    u32 gpe0_block;                    /* GPE0_STS + GPE0_EN */
    u32 gpe1_block;                    /* GPE1_STS + GPE1_EN (선택) */
    u8  gpe0_block_length;
    u8  gpe1_block_length;

    u32 flags;                         /* 주요 플래그 비트 */
#define ACPI_FADT_HW_REDUCED      (1 << 20)  /* HW-Reduced 모드 (ARM) */
#define ACPI_FADT_LOW_POWER_S0    (1 << 21)  /* S0ix/Modern Standby */

    /* ACPI 2.0+ 64-bit 확장 주소 */
    struct acpi_generic_address xfacs;
    struct acpi_generic_address xdsdt;
    struct acpi_generic_address xpm1a_event_block;
    /* ... */
};

MADT (Multiple APIC Description Table)

MADT는 시스템의 인터럽트 컨트롤러(APIC, GIC) 토폴로지를 기술합니다. 가변 길이 서브타입 엔트리의 배열로 구성됩니다.

/* MADT 서브타입 — include/acpi/actbl1.h */
enum acpi_madt_type {
    ACPI_MADT_TYPE_LOCAL_APIC           = 0,  /* 프로세서 Local APIC */
    ACPI_MADT_TYPE_IO_APIC              = 1,  /* I/O APIC */
    ACPI_MADT_TYPE_INTERRUPT_OVERRIDE   = 2,  /* ISA IRQ 재매핑 */
    ACPI_MADT_TYPE_NMI_SOURCE           = 3,  /* NMI 소스 */
    ACPI_MADT_TYPE_LOCAL_APIC_NMI       = 4,  /* Local APIC NMI (LINT) */
    ACPI_MADT_TYPE_LOCAL_X2APIC         = 9,  /* x2APIC (APIC ID > 255) */
    ACPI_MADT_TYPE_LOCAL_X2APIC_NMI     = 10, /* x2APIC NMI */
    ACPI_MADT_TYPE_GENERIC_INTERRUPT    = 11, /* ARM GIC CPU Interface */
    ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR  = 12, /* ARM GIC Distributor */
    ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR = 14, /* ARM GICv3 Redistributor */
    ACPI_MADT_TYPE_GENERIC_ITS          = 15, /* ARM GIC ITS */
    ACPI_MADT_TYPE_MULTIPROC_WAKEUP    = 16, /* Multiprocessor Wakeup (v6.4) */
};

/* Local APIC 서브타입 구조체 */
struct acpi_madt_local_apic {
    struct acpi_subtable_header header;  /* type=0, length=8 */
    u8  processor_id;                    /* ACPI Processor UID */
    u8  id;                               /* Local APIC ID */
    u32 lapic_flags;                     /* bit 0: Enabled */
};

DMAR / IVRS (IOMMU 테이블)

DMA Remapping(Intel VT-d)과 I/O Virtualization(AMD-Vi)의 하드웨어 유닛 정보를 기술합니다.

/* Intel DMAR — include/acpi/actbl2.h */
struct acpi_dmar_hardware_unit {       /* DRHD — DMA Remapping HW Unit */
    struct acpi_dmar_header header;
    u8  flags;
#define ACPI_DMAR_INCLUDE_ALL    (1)    /* 모든 디바이스에 적용 */
    u8  reserved;
    u16 segment;                        /* PCI 세그먼트 번호 */
    u64 address;                        /* 레지스터 베이스 주소 */
    /* 이후 가변 길이 Device Scope 엔트리 */
};

/* RMRR — Reserved Memory Region Reporting */
struct acpi_dmar_reserved_memory {
    struct acpi_dmar_header header;
    u16 reserved;
    u16 segment;
    u64 base_address;                   /* 예약 영역 시작 */
    u64 end_address;                    /* 예약 영역 끝 */
};

/* 커널 DMAR 초기화 — drivers/iommu/intel/dmar.c */
int __init dmar_table_init(void)
{
    dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl,
                         DMAR_MAX_TYPE, dmar_cb);
    /* DRHD → iommu 할당, RMRR → identity mapping 설정 */
}

HMAT (Heterogeneous Memory Attribute Table)

HMAT는 이기종 메모리 토폴로지(HBM, CXL 메모리, PMEM 등)의 대역폭(Bandwidth)/지연 속성을 기술합니다. NUMA 페이지에서 다룬 SRAT/SLIT이 노드 간 거리를 표현하는 반면, HMAT는 이니시에이터(CPU)↔타겟(메모리) 쌍의 정량적 성능 수치를 제공합니다.

/* HMAT 메모리 근접성 도메인 속성 — include/acpi/actbl2.h */
struct acpi_hmat_locality {
    struct acpi_hmat_structure header;
    u8  flags;
    u8  data_type;                       /* 0=Access Latency, 1=Read Latency */
                                          /* 2=Write Latency, 3=Access BW    */
                                          /* 4=Read BW, 5=Write BW           */
    u8  min_transfer_size;
    u8  reserved;
    u32 number_of_initiator_pds;         /* 이니시에이터 도메인 수 */
    u32 number_of_target_pds;             /* 타겟 도메인 수 */
    u64 entry_base_unit;                  /* 나노초 또는 MB/s 기본 단위 */
    /* 이후 initiator PD 배열 + target PD 배열 + entry 행렬 */
};

/* 커널 HMAT 파싱 — drivers/acpi/numa/hmat.c */
static int __init hmat_parse_locality(union acpi_subtable_headers *header, ...)
{
    /* 지연/대역폭 행렬을 memory target에 연결 */
    hmat_update_target_access(target, locality, entry);
    /* → /sys/devices/system/node/nodeN/access0/initiators/ */
}

BERT / HEST / ERST / EINJ (하드웨어 에러 처리)

APEI(ACPI Platform Error Interface) 프레임워크는 4개의 테이블로 구성되며, 머신체크(MCE)를 넘어선 플랫폼 수준 에러 처리를 지원합니다.

APEI / GHES 로그를 읽는 순서

GHES는 "에러가 났다"는 사실만 던지는 것이 아니라, 펌웨어가 기록한 CPER(Common Platform Error Record)를 커널이 해석해 printk로 풀어주는 구조입니다. 따라서 실제 분석은 "HEST가 어떤 source를 정의했는가"와 "runtime에 어떤 CPER section이 올라왔는가"를 함께 봐야 합니다.

# 전형적인 GHES 로그 흐름 예시
{Hardware Error}: Hardware error from APEI Generic Hardware Error Source: 0
{Hardware Error}: It has been corrected by h/w and requires no further action
{Hardware Error}: event severity: corrected
{Hardware Error}: section_type: PCIe error
{Hardware Error}: port_type: PCIe end point
{Hardware Error}: device_id: 0000:5e:00.0

놓치기 쉬운 보조 테이블

실제 플랫폼 디버깅에서는 FADT나 MADT만으로 끝나지 않습니다. 아래 테이블들은 "왜 이 플랫폼만 이렇게 동작하는가"를 설명하는 단서가 되는 경우가 많습니다.

SRAT / SLIT (NUMA 토폴로지 테이블)

NUMA(Non-Uniform Memory Access) 시스템에서 CPU와 메모리의 물리적 배치를 OS에 알려주는 핵심 테이블입니다. 커널의 메모리 할당기와 스케줄러가 locality를 고려한 최적 결정을 내리려면 이 정보가 필수입니다.

SRAT (Static Resource Affinity Table)는 각 CPU(APIC ID)와 메모리 범위를 특정 proximity domain(NUMA 노드)에 매핑합니다:

SLIT (System Locality Information Table)는 proximity domain 간 상대적 거리를 행렬로 표현합니다. 자기 자신의 거리는 항상 10이며, 원격 노드는 20, 30 등으로 증가합니다:

# NUMA 토폴로지 확인
cat /sys/devices/system/node/node*/distance
# 예시 출력 (4-node NUMA):
# node0: 10 21 31 41
# node1: 21 10 41 31
# node2: 31 41 10 21
# node3: 41 31 21 10

# 노드별 CPU/메모리 매핑 확인
numactl --hardware
# available: 4 nodes (0-3)
# node 0 cpus: 0 1 2 3 4 5
# node 0 size: 32768 MB
# node distances:
# node   0   1   2   3
#   0:  10  21  31  41
#   1:  21  10  41  31
#   2:  31  41  10  21
#   3:  41  31  21  10

# SRAT 테이블 원본 덤프
acpidump -b -n SRAT | iasl -d srat.dat

PPTT (Processor Properties Topology Table)

PPTT는 ACPI 6.0에서 도입된 테이블로, CPU의 물리적 계층 구조와 캐시 토폴로지를 기술합니다. x86에서는 CPUID를 통해 이 정보를 얻지만, ARM64 서버에서는 PPTT가 유일한 표준 소스입니다.

PPTT는 두 가지 구조 타입으로 구성됩니다:

# PPTT 기반 캐시 토폴로지 확인 (ARM64 서버)
lscpu --extended
# CPU  NODE  SOCKET  CORE  L1d  L1i  L2    L3
# 0    0     0       0     0    0    0     0
# 1    0     0       1     1    1    1     0

# sysfs 캐시 정보 (PPTT에서 파생)
cat /sys/devices/system/cpu/cpu0/cache/index2/size
# 1024K
cat /sys/devices/system/cpu/cpu0/cache/index2/type
# Unified
cat /sys/devices/system/cpu/cpu0/cache/index2/ways_of_associativity
# 8

IORT (I/O Remapping Table) — ARM SMMU

IORT는 ARM64 플랫폼에서 x86의 DMAR(Intel VT-d)에 해당하는 역할을 합니다. PCIe 디바이스의 Requester ID(RID)를 SMMU의 StreamID로 매핑하고, SMMU 디바이스 자체의 속성을 기술합니다.

IORT는 여러 노드 타입으로 구성됩니다:

IORT의 핵심 개념은 ID 매핑(Output Reference)입니다. 각 노드는 하나 이상의 ID 매핑 항목을 가지며, 입력 ID 범위를 출력 ID 범위로 변환하고 다음 노드를 가리킵니다:

# IORT 테이블 디컴파일
acpidump -b -n IORT
iasl -d iort.dat

# 커널 IORT 파싱 결과 확인
dmesg | grep -i iort
# [    0.123456] ACPI: IORT 0x00000000BFFC0000 0001A8 (v03 ARM    JUNO     ...)

# SMMU 디바이스 매핑 확인
dmesg | grep -i smmu
# [    0.234567] arm-smmu 2b400000.smmu: probing hardware configuration...
# [    0.234890] arm-smmu 2b400000.smmu: SMMUv3: IDR0 0x00246014

# IOMMU 그룹 확인
ls /sys/kernel/iommu_groups/*/devices/

ACPI 전원 관리

ACPI는 시스템 전체(Global/Sleep)부터 개별 디바이스(Device)까지 계층적 전원 상태를 정의합니다.

G-states (Global States)

G-states는 시스템 전체의 전원 상태를 나타냅니다:

• G0 (Working) — 시스템 정상 동작. CPU가 S0에서 명령 실행 중.
• G1 (Sleeping) — 시스템 절전. S1~S4 중 하나의 Sleep state.
• G2 (Soft Off) — S5, OS가 종료되었으나 PSU 대기 전원 공급. 전원 버튼으로 재시작(Reboot) 가능.
• G3 (Mechanical Off) — 전원 완전 차단. PSU 스위치 또는 전원 코드 분리 상태.

S-states (Sleep States)

Linux 절전 인터페이스와 ACPI 매핑

리눅스 사용자는 보통 /sys/power/state와 /sys/power/mem_sleep를 통해 절전을 보지만, 이 인터페이스는 ACPI S-state와 완전히 1:1 대응하지는 않습니다. 특히 s2idle은 소프트웨어적으로 모든 장치를 저전력으로 내리는 일반 메커니즘이며, 플랫폼이 충분히 협조할 때만 실제 S0ix residency가 깊게 쌓입니다.

S0ix / Modern Standby

S0ix는 ACPI의 Low Power S0 Idle capability를 실무에서 부르는 표현입니다. 인텔의 Modern Standby 용어와 자주 함께 쓰이지만, 본질은 "시스템이 S0에 머문 채 플랫폼 전체가 깊은 저전력 residency로 진입하는 것"입니다. FADT의 LOW_POWER_S0 플래그(bit 21)는 이 가능성을 알리며, 실제 residency 품질은 LPIT와 SoC 전원 컨트롤러 구현에 좌우됩니다.

/* drivers/acpi/sleep.c — S0ix 지원 확인 */
static bool acpi_s2idle_supported(void)
{
    /* FADT LOW_POWER_S0 플래그 확인 */
    if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
        /* LPIT (Low Power Idle Table) 파싱 */
        lpit_read_residency_count_address();
        return true;
    }
    return false;
}

/* /sys/power/mem_sleep 에서 s2idle 선택:
 * echo s2idle > /sys/power/mem_sleep
 * echo mem > /sys/power/state
 *
 * Intel PMC 기반 시스템이라면 S0ix residency 확인:
 * cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec */

여기서 중요한 점은 s2idle이 "진입 방법"이고 S0ix는 "플랫폼이 실제 달성한 전력 상태"라는 것입니다. 장치 드라이버(Device Driver) 한 개가 runtime suspend에 실패해도 사용자는 절전에 들어간 것처럼 보이지만, 실제 전력은 S0ix에 못 미치는 경우가 흔합니다.

D-states (Device Power States)

각 디바이스는 독립적으로 D0~D3cold 전원 상태를 가집니다:

• D0 (Fully On) — 디바이스 완전 동작 상태
• D1, D2 — 중간 절전 (디바이스 클래스별 정의)
• D3hot — 소프트웨어적 전원 차단, PCI 설정 공간 접근 가능, Vaux 유지
• D3cold — 물리적 전원 차단, 버스 전원 제거, 재초기화 필요

/* drivers/acpi/device_pm.c — 디바이스 전원 상태 전환 */
int acpi_device_set_power(struct acpi_device *device, int state)
{
    /* 현재 상태 확인 */
    int cur_state;
    acpi_device_get_power(device, &cur_state);

    if (state == ACPI_STATE_D3_COLD) {
        /* D3cold: _PS3 실행 후 전원 리소스 해제 */
        acpi_evaluate_object(device->handle, "_PS3", NULL, NULL);
        acpi_power_off_list(&device->power.states[state].resources);
    } else if (state == ACPI_STATE_D0) {
        /* D0 복원: 전원 리소스 켜기 → _PS0 실행 */
        acpi_power_on_list(&device->power.states[state].resources);
        acpi_evaluate_object(device->handle, "_PS0", NULL, NULL);
    }
    return 0;
}

Power Resource Objects와 _PR0/_PR3

D-state 설명만 보면 장치 전원이 개별 메서드 _PS0/_PS3로만 전환되는 것처럼 보이지만, 실제 플랫폼은 하나의 전원 레일이나 클럭 공급원을 여러 장치가 공유하는 경우가 많습니다. 이때 ACPI는 Power Resource 오브젝트를 별도로 만들고, 각 장치가 D-state별로 어떤 리소스를 필요로 하는지 _PR0~_PR3로 연결합니다.

C/P-states와 ACPI 관계

C-states(CPU Idle)와 P-states(CPU Performance)는 ACPI가 정의한 프로세서 전원 상태입니다. 자세한 P-state/CPPC 구현은 ktime/Clock 페이지를 참조하세요.

/* ACPI _CST (C-State) 메서드 — 커널 cpuidle 연동 */

/* ASL에서 _CST 반환 형식:
 * Package {
 *   NumEntries,
 *   Package { Register, Type, Latency, Power },  // C1
 *   Package { Register, Type, Latency, Power },  // C2
 *   Package { Register, Type, Latency, Power },  // C3
 * }
 */

/* drivers/acpi/processor_idle.c */
static int acpi_processor_get_cstate_info(struct acpi_processor *pr)
{
    /* _CST 평가하여 C-state 정보 추출 */
    status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);

    /* cpuidle 프레임워크에 C-state 등록 */
    for (i = 1; i <= pr->power.count; i++) {
        cx = &pr->power.states[i];
        /* C1: MWAIT, C2: IO port, C3: MWAIT + BM check */
    }
}

CPPC와 PPTT: 추상 성능 스케일과 토폴로지

전통적인 ACPI P-state는 소수의 성능 점을 정의하는 방식이라 현대 CPU의 세밀한 제어에는 한계가 있습니다. CPPC(Collaborative Processor Performance Control)는 주파수 대신 "연속적이고 단위 없는 추상 성능 스케일"을 제공해, OS가 목표 성능만 제시하고 하드웨어가 세부 동작을 조정할 수 있게 합니다. Linux는 이를 cppc_acpi, amd-pstate, 일부 플랫폼의 pcc-cpufreq 경로로 소비합니다.

# CPU0의 CPPC 노출 확인
$ ls /sys/devices/system/cpu/cpu0/acpi_cppc/
feedback_ctrs  highest_perf  lowest_freq  lowest_nonlinear_perf
lowest_perf    nominal_freq  nominal_perf reference_perf

# 대표 값 확인
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/feedback_ctrs

Runtime PM과 ACPI D-states 연동

Linux의 Runtime PM 프레임워크는 디바이스 드라이버가 개별 장치를 사용하지 않을 때 자동으로 저전력 상태로 전환하는 메커니즘입니다. ACPI 플랫폼에서는 이 전환이 ACPI D-state와 직접 연동됩니다. Runtime PM의 suspend 콜백이 호출되면 ACPI core가 _PS3 메서드를 실행해 D3hot으로 전환하고, resume 콜백 시 _PS0을 호출해 D0로 복귀합니다.

/* 드라이버에서 Runtime PM 활성화 (probe 함수 내) */
pm_runtime_enable(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_allow(&pdev->dev);
/* → idle 콜백 실행 시 ACPI는 자동으로 _PS3 호출 (D3hot 진입)
 * → 접근 시 pm_runtime_get_sync() → ACPI _PS0 호출 (D0 복귀) */

/* drivers/acpi/device_pm.c — Runtime PM ↔ ACPI 연동 핵심 */
int acpi_dev_runtime_suspend(struct device *dev)
{
    struct acpi_device *adev = ACPI_COMPANION(dev);
    if (!adev)
        return 0;

    /* 장치를 D3hot(또는 가능하면 D3cold)으로 전환 */
    acpi_device_set_power(adev, ACPI_STATE_D3_HOT);
    return 0;
}

int acpi_dev_runtime_resume(struct device *dev)
{
    struct acpi_device *adev = ACPI_COMPANION(dev);
    if (!adev)
        return 0;

    /* D0로 복귀: 전원 리소스 ON → _PS0 실행 */
    acpi_device_set_power(adev, ACPI_STATE_D0);
    return 0;
}

# Runtime PM 상태 확인
$ cat /sys/devices/pci0000:00/0000:00:1f.3/power/runtime_status
active

# ACPI 전원 상태 확인
$ cat /sys/devices/pci0000:00/0000:00:1f.3/power_state
D0

# Runtime PM 타임아웃 설정 (밀리초)
$ cat /sys/devices/pci0000:00/0000:00:1f.3/power/autosuspend_delay_ms
2000

# Runtime PM 강제 suspend
$ echo auto > /sys/devices/pci0000:00/0000:00:1f.3/power/control

Suspend/Resume 커널 흐름 상세

시스템 전체 절전(S3 Suspend to RAM)은 사용자 공간(User Space)에서 /sys/power/state에 쓰기로 시작하여, 커널의 PM core, 디바이스 드라이버, ACPI 서브시스템, 그리고 최종적으로 하드웨어까지 계층적으로 진행됩니다. 아래는 S3 진입부터 복귀까지의 전체 흐름입니다.

/* kernel/power/suspend.c — 전체 흐름 요약 */
static int suspend_enter(suspend_state_t state, bool *wakeup)
{
    /* 1. 플랫폼 준비: acpi_suspend_begin() */
    error = platform_suspend_begin(state);

    /* 2. 디바이스 suspend: .suspend_late() + .suspend_noirq() */
    error = dpm_suspend_late(PMSG_SUSPEND);
    error = dpm_suspend_noirq(PMSG_SUSPEND);

    /* 3. Non-boot CPU 오프라인 */
    error = suspend_disable_secondary_cpus();

    /* 4. ACPI 진입: SLP_TYP + SLP_EN → 하드웨어 슬립 */
    error = platform_suspend_enter(state);
    /* === CPU가 여기서 멈춤 === */

    /* 5. Wake 후: 여기서부터 재개 */
    suspend_enable_secondary_cpus();

    /* 6. 디바이스 resume */
    dpm_resume_noirq(PMSG_RESUME);
    dpm_resume_early(PMSG_RESUME);
    return 0;
}

/* drivers/acpi/sleep.c — ACPI S3 진입 */
static int acpi_suspend_enter(suspend_state_t pm_state)
{
    /* PM1a/PM1b 레지스터에 SLP_TYP 값 설정 */
    u8 type_a = acpi_sleep_state_data.sleep_type_a;
    u8 type_b = acpi_sleep_state_data.sleep_type_b;

    /* SLP_EN 비트를 설정하면 CPU가 즉시 정지 */
    acpi_enter_sleep_state(ACPI_STATE_S3);
    /* ... wake 후 여기로 복귀 ... */
    acpi_leave_sleep_state(ACPI_STATE_S3);
    return ACPI_SUCCESS(status) ? 0 : -EFAULT;
}

Lid/Power Button 이벤트 처리

노트북의 뚜껑 개폐와 전원 버튼 입력은 ACPI에서 시작하여 Linux input 서브시스템으로 전달됩니다. 과거에는 /proc/acpi/button/을 통해 노출되었으나, 현재는 input 이벤트(SW_LID, KEY_POWER)가 주된 인터페이스입니다.

/* drivers/acpi/button.c — Lid 이벤트 처리 */
static void acpi_button_notify(struct acpi_device *device, u32 event)
{
    struct acpi_button *button = acpi_driver_data(device);

    switch (button->type) {
    case ACPI_BUTTON_TYPE_LID:
        /* _LID 메서드를 호출해 현재 상태 확인 */
        acpi_lid_update_state(device, true);
        /* SW_LID 이벤트를 input 서브시스템으로 전달 */
        input_report_switch(button->input, SW_LID, !state);
        input_sync(button->input);
        break;

    case ACPI_BUTTON_TYPE_POWER:
        input_report_key(button->input, KEY_POWER, 1);
        input_sync(button->input);
        input_report_key(button->input, KEY_POWER, 0);
        input_sync(button->input);
        break;
    }
}

/* systemd-logind가 input 이벤트를 수신:
 * /etc/systemd/logind.conf:
 *   HandleLidSwitch=suspend       ← 뚜껑 닫으면 절전
 *   HandlePowerKey=poweroff       ← 전원 버튼 누르면 종료
 *   HandleLidSwitchDocked=ignore  ← 도킹 시 뚜껑 무시
 */

# ACPI 이벤트 실시간 모니터링
$ acpi_listen
button/lid LID close
button/lid LID open
button/power PBTN 00000080 00000000

# Lid 상태 확인 (구형 인터페이스)
$ cat /proc/acpi/button/lid/LID0/state
state:      open

# Input 이벤트로 확인 (권장)
$ libinput debug-events --show-keycodes | grep -i lid
-event3  DEVICE_ADDED   Lid Switch

# systemd-logind 설정 확인
$ loginctl show-session -p HandleLidSwitch

ACPI 열 관리

ACPI Thermal Zone은 펌웨어와 OS 간 열 관리 인터페이스를 정의합니다. ASL 코드로 온도 임계값과 쿨링 정책을 선언하면, 커널의 thermal 프레임워크가 이를 실행합니다.

Thermal Zone ASL 메서드

/* Thermal Zone 정의 예시 (ASL) */
ThermalZone (TZ00, 0) {
    /* 현재 온도 반환 (단위: 0.1K, 3000 = 27°C) */
    Method (_TMP, 0, Serialized) {
        Return (\_SB.EC0.RTMP())
    }

    /* Passive cooling 임계 온도 */
    Method (_PSV, 0) { Return (3630) }  /* 90°C */

    /* Passive cooling 대상 프로세서 리스트 */
    Method (_PSL, 0) {
        Return (Package () { \_PR.CPU0, \_PR.CPU1 })
    }

    /* Passive cooling 계수: 온도 추적 반응 속도 */
    Name (_TC1, 1)   /* 현재 온도에 대한 가중치 */
    Name (_TC2, 5)   /* 이전 온도에 대한 가중치 */
    Name (_TSP, 100) /* 폴링 주기 (0.1초 단위, 10초) */

    /* Critical 온도 — 이 온도 초과 시 즉시 셧다운 */
    Method (_CRT, 0) { Return (3830) }  /* 110°C */

    /* Hot 온도 — S4(hibernate) 전환 트리거 */
    Method (_HOT, 0) { Return (3780) }  /* 105°C */
}

커널 thermal 프레임워크 연동

/* drivers/acpi/thermal.c — ACPI thermal zone 등록 */
static int acpi_thermal_add(struct acpi_device *device)
{
    struct acpi_thermal *tz;

    /* ACPI thermal zone 정보 수집 */
    acpi_thermal_get_temperature(tz);       /* _TMP */
    acpi_thermal_get_trip_points(tz);       /* _CRT, _HOT, _PSV, _ACx */

    /* 커널 thermal 프레임워크에 등록 */
    tz->thermal_zone = thermal_zone_device_register(
        "acpitz",               /* 이름 */
        trips,                   /* trip point 수 */
        tz,                      /* 드라이버 데이터 */
        &acpi_thermal_zone_ops,  /* get_temp, get_trip_type ... */
        NULL, passive_delay, polling_delay
    );
}

sysfs 인터페이스

# Thermal zone 정보 확인
$ ls /sys/class/thermal/thermal_zone0/
temp  type  trip_point_0_temp  trip_point_0_type  policy  mode

# 현재 온도 (밀리도, 45000 = 45°C)
$ cat /sys/class/thermal/thermal_zone0/temp
45000

# trip point 확인
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_type
critical
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
110000

# 쿨링 디바이스 상태
$ cat /sys/class/thermal/cooling_device0/type
Processor
$ cat /sys/class/thermal/cooling_device0/cur_state
0
$ cat /sys/class/thermal/cooling_device0/max_state
10

Thermal Zone 메서드 상세

ACPI Thermal Zone은 단순히 온도를 읽는 것 이상으로, 다단계 쿨링 정책, 폴링 주기, 임계값 히스테리시스까지 정의합니다. 아래 표는 Thermal Zone에서 사용 가능한 전체 메서드 목록입니다.

쿨링 정책 알고리즘

ACPI thermal 프레임워크는 passive cooling과 active cooling 두 가지 알고리즘을 병행합니다. Passive cooling은 온도를 임계값 이하로 유지하기 위해 CPU 성능을 제한하고, active cooling은 팬 단계를 제어합니다.

Passive Cooling 알고리즘

Passive cooling은 PI(Proportional-Integral) 제어에 기반합니다. 매 _TSP 주기마다 다음 공식으로 성능 제한 수준을 계산합니다:

Performance_delta = _TC1 × (Tn - Tn-1) + _TC2 × (Tn - Ttrip)

여기서:
  Tn     = 현재 온도
  Tn-1   = 이전 샘플 온도
  Ttrip  = _PSV (passive trip point)
  _TC1   = 온도 변화율 계수 (미분 항)
  _TC2   = 온도 편차 계수 (비례 항)

Performance_delta > 0  → 성능 한 단계 낮춤 (P-state 하향)
Performance_delta < 0  → 성능 한 단계 올림 (P-state 상향)
Performance_delta = 0  → 현 상태 유지

Active Cooling 팬 단계 선택

_AC0 > _AC1 > _AC2 > ... > _AC9  (온도 내림차순)

온도 상승 시:
  T >= _AC0 → _AL0 디바이스 활성화 (최대 풍량)
  T >= _AC1 → _AL1 디바이스 활성화 (중간 풍량)
  ...

온도 하강 시 (히스테리시스):
  T < _AC0 - hysteresis → _AL0 비활성화
  커널 기본 히스테리시스: 약 2°C

INT3400 — DPTF (Dynamic Platform and Thermal Framework)

Intel DPTF(Dynamic Platform and Thermal Framework)는 ACPI Thermal Zone의 단일 센서-단일 쿨러 모델을 넘어서, 다중 센서 + 다중 쿨러 + 다중 정책을 지원하는 확장 프레임워크입니다. DSDT에서 INT3400 디바이스로 선언되며, 피부 온도 센서, 배터리 온도, SoC 내부 온도 등을 종합해 사용자 체감 열 관리를 수행합니다.

# DPTF 지원 확인
$ ls /sys/bus/acpi/devices/ | grep INT340
INT3400:00
INT3401:00
INT3403:00
INT3403:01

# DPTF thermal zone 정보
$ ls /sys/class/thermal/ | grep int340
thermal_zone1   # INT3401 (CPU)
thermal_zone2   # INT3403 (피부 온도 센서)

# thermald 데몬 상태 확인 (사용자 공간 DPTF 구현)
$ systemctl status thermald
$ cat /etc/thermald/thermal-conf.xml

GPE & SCI

ACPI 이벤트 모델의 핵심은 SCI(System Control Interrupt)와 GPE(General Purpose Event)입니다. 모든 ACPI 런타임 이벤트는 SCI를 통해 커널에 전달됩니다.

SCI (System Control Interrupt)

SCI는 ACPI 이벤트를 전달하는 공유 레벨 트리거 인터럽트입니다. FADT의 sci_interrupt 필드(보통 IRQ 9)로 지정됩니다. 하나의 SCI로 전원 버튼, 뚜껑 닫힘, GPE, EC 이벤트 등 모든 ACPI 이벤트가 멀티플렉싱됩니다.

GPE 블록 레지스터

GPE 블록은 Status/Enable 레지스터 쌍으로 구성됩니다. FADT에 GPE0/GPE1 블록 주소가 정의되며, 각 비트가 하나의 GPE 이벤트에 대응합니다.

커널 GPE 처리

/* drivers/acpi/acpica/evgpe.c — GPE 처리 흐름 */

/* GPE 핸들러 등록 */
acpi_status acpi_install_gpe_handler(
    acpi_handle gpe_device,
    u32 gpe_number,
    u32 type,                          /* ACPI_GPE_LEVEL/EDGE_TRIGGERED */
    acpi_gpe_handler address,          /* 콜백 함수 */
    void *context)
{
    /* GPE 번호에 해당하는 레지스터 비트 계산 */
    gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);

    /* 핸들러를 GPE 이벤트에 연결 */
    gpe_event_info->dispatch.handler = handler;
    acpi_ev_enable_gpe(gpe_event_info);
}

/* SCI → GPE dispatch 경로:
 * acpi_ev_sci_xrupt_handler()
 *  → acpi_ev_gpe_detect()        (어떤 GPE 비트가 set되었는지 확인)
 *   → acpi_ev_gpe_dispatch()     (해당 GPE의 핸들러 또는 _Lxx/_Exx 실행)
 */

# GPE 인터럽트 통계 확인
$ cat /sys/firmware/acpi/interrupts/gpe_all
    1247

# 개별 GPE 확인 (GPE 0x6E = 리드 닫힘/열림 이벤트 등)
$ cat /sys/firmware/acpi/interrupts/gpe6E
      23   enabled   unmasked

# SCI 총 인터럽트 수
$ cat /sys/firmware/acpi/interrupts/sci
    1523

# 문제 있는 GPE 비활성화 (GPE storm 대응)
$ echo disable > /sys/firmware/acpi/interrupts/gpe6E

GPE 기반 Wake 이벤트 설정

시스템이 절전 상태(S3/S4)에 있을 때 특정 이벤트로 깨어나려면, 해당 GPE가 suspend 진입 전에 "armed" 상태로 설정되어야 합니다. ACPI는 _PRW(Power Resources for Wake) 메서드를 통해 각 디바이스의 wake 능력을 선언합니다. _PRW는 GPE 번호와 해당 디바이스가 깨울 수 있는 최저 S-state를 Package로 반환합니다.

/* _PRW 반환 형식: Package { GPE 번호, 최저 wake S-state } */
Device (NIC0) {
    Name (_HID, "PNP0A03")
    Method (_PRW, 0) {
        Return (Package () {
            0x0D,  /* GPE 번호 0x0D가 wake source */
            0x04   /* S4까지 wake 가능 */
        })
    }
}

/* USB 디바이스의 wake 선언 */
Device (RHUB) {
    Method (_PRW, 0) {
        Return (Package () {
            0x6D,  /* GPE 0x6D */
            0x03   /* S3까지 wake 가능 */
        })
    }
}

# Wake 가능한 GPE와 발생 횟수 확인
$ cat /sys/firmware/acpi/interrupts/gpe_all
    1247

# 개별 GPE 상태 확인
$ cat /sys/firmware/acpi/interrupts/gpe0D
      5   enabled   unmasked

# 특정 GPE 비활성화 (GPE storm 또는 불필요한 wake 방지)
$ echo disable > /sys/firmware/acpi/interrupts/gpe17

# 특정 GPE 재활성화
$ echo enable > /sys/firmware/acpi/interrupts/gpe17

# Wake 가능한 디바이스 목록 확인
$ cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
LID0      S4    *enabled   platform:PNP0C0D:00
SLPB      S3    *enabled   platform:PNP0C0E:00
GLAN      S4    *enabled   pci:0000:00:1f.6
XHC       S3    *enabled   pci:0000:00:14.0

# 특정 디바이스의 wake 기능 토글
$ echo XHC > /proc/acpi/wakeup    # enabled ↔ disabled 토글

Fixed Events 상세

Fixed Events는 GPE와 달리 PM1 Status/Enable 레지스터에 비트 위치가 고정된 이벤트입니다. ACPI 스펙이 비트 번호를 지정하므로 AML 메서드 없이도 ACPICA가 직접 처리할 수 있습니다.

/* drivers/acpi/acpica/evxfevnt.c — Fixed Event 처리 흐름 */

/* SCI 인터럽트 핸들러에서 Fixed Event 확인 */
u32 acpi_ev_fixed_event_detect(void)
{
    u32 int_status = ACPI_INTERRUPT_NOT_HANDLED;

    /* PM1 Status와 Enable 레지스터 읽기 */
    acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &fixed_status);
    acpi_hw_register_read(ACPI_REGISTER_PM1_ENABLE, &fixed_enable);

    /* enabled && status가 모두 set된 이벤트만 dispatch */
    for (i = 0; i < ACPI_NUM_FIXED_EVENTS; i++) {
        if ((fixed_status & acpi_gbl_fixed_event_info[i].status_bit_mask) &&
            (fixed_enable & acpi_gbl_fixed_event_info[i].enable_bit_mask)) {
            acpi_ev_fixed_event_dispatch(i);
            int_status |= ACPI_INTERRUPT_HANDLED;
        }
    }
    return int_status;
}

/* Fixed Event dispatch: 등록된 핸들러 호출 */
static u32 acpi_ev_fixed_event_dispatch(u32 event)
{
    /* Status 비트 클리어 (W1C: Write 1 to Clear) */
    acpi_hw_clear_fixed_event(event);

    /* 등록된 핸들러 호출 (예: power button → acpi_button.c) */
    return acpi_gbl_fixed_event_handlers[event].handler(
        acpi_gbl_fixed_event_handlers[event].context);
}

Embedded Controller (EC)

EC(Embedded Controller)는 노트북/랩톱에서 배터리, 팬, 키보드, 온도 센서 등을 제어하는 마이크로컨트롤러입니다. x86 I/O 포트(0x62/0x66)를 통해 호스트 CPU와 통신합니다.

EC 프로토콜

/* EC I/O 포트 및 상태 비트 */
#define ACPI_EC_DATA_PORT     0x62   /* 데이터 레지스터 */
#define ACPI_EC_COMMAND_PORT  0x66   /* 커맨드/상태 레지스터 */

/* 상태 레지스터 비트 */
#define ACPI_EC_FLAG_OBF      0x01   /* Output Buffer Full */
#define ACPI_EC_FLAG_IBF      0x02   /* Input Buffer Full */
#define ACPI_EC_FLAG_SCI_EVT  0x20   /* SCI Event Pending */

/* EC 커맨드 */
#define ACPI_EC_COMMAND_READ  0x80   /* 바이트 읽기 */
#define ACPI_EC_COMMAND_WRITE 0x81   /* 바이트 쓰기 */
#define ACPI_EC_COMMAND_QUERY 0x84   /* SCI 이벤트 쿼리 */
#define ACPI_EC_BURST_ENABLE  0x82   /* 버스트 모드 활성화 */

/* drivers/acpi/ec.c — EC 트랜잭션 */
static int acpi_ec_transaction(struct acpi_ec *ec,
                               struct transaction *t)
{
    /* 1. IBF가 클리어될 때까지 대기 */
    ec_poll_guard(ec);

    /* 2. 커맨드 전송 (0x66 포트) */
    outb(t->command, ec->command_addr);

    /* 3. 주소 전송 (0x62 포트) */
    outb(t->wdata[0], ec->data_addr);

    /* 4. OBF 대기 후 데이터 읽기 */
    t->rdata[0] = inb(ec->data_addr);
}

EC 이벤트와 쿼리 메서드

EC가 SCI_EVT 비트를 설정하면 커널이 Query 커맨드(0x84)를 보내 이벤트 번호를 얻고, 해당 _Qxx AML 메서드를 실행합니다.

/* drivers/acpi/ec.c — EC 이벤트 처리 */
static void acpi_ec_event_handler(struct work_struct *work)
{
    /* Query 커맨드로 이벤트 번호 획득 */
    acpi_ec_query(ec, &value);  /* value = 0x00~0xFF */

    /* 해당 _Qxx 메서드 실행 (예: _Q0D = 밝기 변경) */
    snprintf(name, sizeof(name), "_Q%02X", value);
    acpi_evaluate_object(ec->handle, name, NULL, NULL);
}

EC 디버깅

# EC 상태 확인
$ cat /sys/kernel/debug/ec/ec0/io

# EC 이벤트 로그
$ dmesg | grep -i "ec:"
[    0.512] ACPI: EC: EC started
[    0.512] ACPI: EC: interrupt mode

# EC 디버깅 활성화
$ echo 0x10 > /sys/module/acpi/parameters/debug_level

배터리, AC 어댑터, 뚜껑, 전원 버튼

노트북 계열 플랫폼에서 ACPI는 단순 부팅 테이블이 아니라 사용자 체감 기능의 핵심 제어 경로입니다. 배터리 잔량, AC 연결 여부, 뚜껑 개폐, 전원 버튼 입력은 대부분 ACPI 디바이스와 AML 메서드를 거쳐 커널 power_supply 또는 input 서브시스템으로 올라옵니다. 이 경로는 EC와 GPE에 강하게 의존하므로, 배터리 문제와 lid wake 문제는 거의 항상 함께 봐야 합니다.

/* 노트북 장치 예시 — DSDT/SSDT 디컴파일에서 자주 보는 형태 */
Device (AC) {
    Name (_HID, "ACPI0003")
    Method (_PSR, 0) { Return (\_SB.PCI0.LPCB.EC0.ACST) }
}

Device (BAT0) {
    Name (_HID, "PNP0C0A")
    Method (_BST, 0) { ... }  /* 상태: charging/discharging */
    Method (_BIX, 0) { ... }  /* 설계 용량, 제조사 정보 */
}

Device (LID0) {
    Name (_HID, "PNP0C0D")
    Method (_LID, 0) { Return (\_SB.PCI0.LPCB.EC0.LIDS) }
}

# 배터리/AC 상태 확인
$ ls /sys/class/power_supply/
AC  BAT0

$ cat /sys/class/power_supply/AC/online
1
$ cat /sys/class/power_supply/BAT0/status
Discharging
$ cat /sys/class/power_supply/BAT0/energy_now

# lid / 버튼 이벤트 확인
$ libinput debug-events | grep -i lid
$ cat /proc/acpi/button/lid/LID0/state

EC Burst Mode

일반 EC 트랜잭션은 한 번에 1바이트씩 읽고 쓰며, 각 바이트마다 IBF/OBF 대기와 상태 확인이 필요합니다. Burst Mode는 ACPI 2.0에서 도입된 최적화로, 한 번의 Burst Enable 커맨드(0x82)를 보낸 뒤 여러 바이트를 연속으로 전송할 수 있게 합니다. EC가 Burst Mode에 있는 동안 호스트 외의 접근은 차단되어, 원자적(atomic) 다중 바이트 읽기/쓰기가 가능합니다.

/* drivers/acpi/ec.c — Burst Mode 진입/해제 */
static int acpi_ec_burst_enable(struct acpi_ec *ec)
{
    u8 d;
    /* BURST_ENABLE 커맨드(0x82) 전송 */
    return acpi_ec_transaction(ec, &(struct transaction) {
        .command = ACPI_EC_BURST_ENABLE,
        .rdata = &d, .rlen = 1,
    });
    /* EC가 0x90을 반환하면 Burst 모드 활성화 확인 */
}

static int acpi_ec_burst_disable(struct acpi_ec *ec)
{
    /* BURST_DISABLE 커맨드(0x83) 전송 */
    return acpi_ec_transaction(ec, &(struct transaction) {
        .command = ACPI_EC_BURST_DISABLE,
    });
    /* EC의 BURST 비트가 클리어되어 일반 모드로 복귀 */
}

/* ASL에서 Burst 접근 예시 */
/*
 * OperationRegion (ECF2, EmbeddedControl, 0x00, 0xFF)
 * Field (ECF2, ByteAcc, Lock, Preserve) {
 *   Offset(0x10),
 *   BIF0, 16,   // 설계 용량
 *   BIF1, 16,   // 마지막 충전 용량
 *   BIF2, 16,   // 설계 전압
 *   ...
 * }
 * // Lock 키워드가 있으면 ACPICA가 자동으로 Burst 모드를 사용합니다.
 */

WMI (Windows Management Instrumentation) 인터페이스

WMI는 ACPI 위에 구축된 벤더 확장 인터페이스입니다. 원래 Windows 전용 기술이었으나, Linux 커널도 drivers/platform/x86/wmi.c를 통해 WMI 디바이스를 지원합니다. 벤더는 DSDT/SSDT에 _WDG(WMI Data GUID) 오브젝트를 정의해 독자적인 기능(핫키, 팬 제어, BIOS 설정, LED, 키보드 백라이트 등)을 WMI 메서드로 노출합니다.

/* drivers/platform/x86/wmi.c — WMI 핵심 API */

/* WMI 메서드 호출 */
acpi_status wmi_evaluate_method(
    const char *guid,      /* WMI GUID 문자열 */
    u8 instance,            /* 인스턴스 번호 */
    u32 method_id,          /* 메서드 ID */
    const struct acpi_buffer *in,
    struct acpi_buffer *out);

/* WMI 이벤트 알림 핸들러 등록 */
acpi_status wmi_install_notify_handler(
    const char *guid,
    wmi_notify_handler handler,
    void *data);

/* 실제 벤더 WMI 드라이버 예시: dell-wmi */
static void dell_wmi_notify(u32 value, void *context)
{
    struct acpi_buffer response = { ACPI_ALLOCATE_BUFFER, NULL };
    union acpi_object *obj;

    wmi_get_event_data(value, &response);
    obj = (union acpi_object *)response.pointer;

    /* 이벤트 타입에 따라 input 키 이벤트 생성 */
    switch (buffer_entry[1]) {
    case 0xe045:  /* 밝기 증가 */
        input_report_key(dell_wmi_input_dev, KEY_BRIGHTNESSUP, 1);
        break;
    case 0xe009:  /* 무선 토글 */
        input_report_key(dell_wmi_input_dev, KEY_RFKILL, 1);
        break;
    }
}

# 시스템에 등록된 WMI 디바이스 확인
$ ls /sys/bus/wmi/devices/
9DBB5994-A997-11DA-B012-B622A1EF5492
ABBC0F5B-8EA1-11D1-00A0-C90629100000

# WMI GUID 정보 확인
$ cat /sys/bus/wmi/devices/9DBB5994-A997-11DA-B012-B622A1EF5492/modalias
wmi:9DBB5994-A997-11DA-B012-B622A1EF5492

# DSDT에서 _WDG 오브젝트 확인 (디컴파일 필요)
$ cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
$ iasl -d dsdt.dat
$ grep -A 5 "_WDG" dsdt.dsl

Operation Regions

Operation Region은 AML 코드가 시스템 자원(메모리, I/O 포트, PCI 설정, EC 등)에 접근하기 위한 주소 공간(Address Space) 추상화입니다. ASL에서 OperationRegion을 선언하고 Field로 개별 비트/바이트를 정의합니다.

/* ASL OperationRegion 예시 — EC 기반 배터리 정보 */
OperationRegion (ERAM, EmbeddedControl, 0x00, 0xFF)
Field (ERAM, ByteAcc, NoLock, Preserve) {
    Offset (0x20),
    BTST, 8,       /* 배터리 상태 (충전/방전) */
    BTCR, 16,      /* 배터리 현재 충전률 */
    BTVL, 16,      /* 배터리 전압 (mV) */
    Offset (0x30),
    FANS, 8,       /* 팬 속도 단계 (0~7) */
    CPUT, 8,       /* CPU 온도 */
}

/* SystemMemory 예시 — MMIO 레지스터 */
OperationRegion (GNVS, SystemMemory, 0xBF7E9000, 0x100)
Field (GNVS, AnyAcc, NoLock, Preserve) {
    OSYS, 16,      /* OS 유형 */
    LIDS, 8,       /* 뚜껑 상태 */
    PWRS, 8,       /* AC 전원 상태 */
}

/* 커널 Operation Region 핸들러 등록 — 커스텀 주소 공간 */
/* drivers/acpi/acpica/evregion.c */

acpi_status acpi_install_address_space_handler(
    acpi_handle device,
    acpi_adr_space_type space_id,   /* GPIO, GenericSerialBus 등 */
    acpi_adr_space_handler handler, /* read/write 콜백 */
    acpi_adr_space_setup setup,     /* 초기화 콜백 */
    void *context);

/* 예: GPIO Operation Region 핸들러
 * drivers/gpio/gpiolib-acpi.c
 * AML의 GPIO 필드 접근 → 커널 gpiod_get_value()/gpiod_set_value() 호출
 */

Operation Region 유형 총정리

ACPI 스펙은 12가지 표준 주소 공간(Region Space)을 정의하며, 각각 커널에서 서로 다른 경로로 하드웨어에 접근합니다. 아래 표는 ACPI 6.5 기준 전체 Region Space를 정리합니다.

커스텀 Operation Region 핸들러 등록

커널 드라이버가 AML에서 사용하는 비표준 주소 공간을 지원하려면 acpi_install_address_space_handler()로 커스텀 핸들러를 등록해야 합니다. 이 API는 특정 ACPI 디바이스 핸들에 주소 공간 핸들러를 연결하여, AML이 해당 Region의 Field를 읽거나 쓸 때 커널 콜백이 호출되도록 합니다.

/* 커스텀 Operation Region 핸들러 구현 패턴 */
/* 핸들러 콜백: AML이 Field를 읽거나 쓸 때 호출 */
static acpi_status my_opregion_handler(
    u32 function,                  /* ACPI_READ 또는 ACPI_WRITE */
    acpi_physical_address address, /* Field 오프셋 (바이트) */
    u32 bit_width,                 /* 접근 폭 (8/16/32/64) */
    u64 *value,                    /* 읽기: 결과 저장 / 쓰기: 입력 값 */
    void *handler_context,         /* 등록 시 전달한 컨텍스트 */
    void *region_context)          /* setup 콜백이 설정한 컨텍스트 */
{
    struct my_device *dev = handler_context;

    if (function == ACPI_READ) {
        *value = my_hw_read(dev, address, bit_width);
        dev_dbg(&dev->pdev->dev,
                "OpRegion READ: offset=0x%llx width=%u val=0x%llx\n",
                address, bit_width, *value);
    } else {
        my_hw_write(dev, address, bit_width, *value);
        dev_dbg(&dev->pdev->dev,
                "OpRegion WRITE: offset=0x%llx width=%u val=0x%llx\n",
                address, bit_width, *value);
    }
    return AE_OK;
}

/* setup 콜백: Region 활성화/비활성화 시 호출 */
static acpi_status my_opregion_setup(
    acpi_handle handle, u32 function,
    void *handler_context, void **region_context)
{
    *region_context = handler_context;
    return AE_OK;
}

/* 드라이버 probe에서 핸들러 등록 */
acpi_status status;
status = acpi_install_address_space_handler(
    handle,
    ACPI_ADR_SPACE_GSBUS,    /* GenericSerialBus (0x09) */
    my_opregion_handler,
    my_opregion_setup,
    my_device);

if (ACPI_FAILURE(status))
    dev_err(&pdev->dev, "OpRegion handler 등록 실패: %s\n",
            acpi_format_exception(status));

/* 드라이버 remove에서 핸들러 해제 */
acpi_remove_address_space_handler(handle,
    ACPI_ADR_SPACE_GSBUS, my_opregion_handler);

GPIO/I2C OpRegion 실전

ACPI 5.0부터 GPIO와 I2C/SPI 장치를 AML에서 직접 제어할 수 있게 되었습니다. 이를 위해 GeneralPurposeIO(0x08)와 GenericSerialBus(0x09) Region Space가 도입되었으며, 리눅스 커널의 gpiolib-acpi.c와 i2c-core-acpi.c가 해당 핸들러를 제공합니다.

/* GPIO Operation Region — LED 제어 예시 */
Device (LEDS) {
    Name (_HID, "MYLED001")

    /* GPIO 커넥션 리소스 정의 */
    Name (GRES, ResourceTemplate () {
        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
                IoRestrictionOutputOnly,
                "\\_SB.GPO0", 0x00,
                ResourceConsumer, , ) { 23 }  // GPIO 핀 23
    })

    /* GPIO Operation Region 선언 */
    OperationRegion (GPIO, GeneralPurposeIO, 0, 1)
    Field (GPIO, ByteAcc, NoLock, Preserve) {
        Connection (GpioIo (Exclusive, PullDefault, 0, 0,
                    IoRestrictionOutputOnly,
                    "\\_SB.GPO0", 0, , ) { 23 }),
        LEDN, 1  /* GPIO pin 23 — 1비트 필드 */
    }

    /* LED ON/OFF 메서드 */
    Method (_ON, 0) { Store (One, LEDN) }
    Method (_OFF, 0) { Store (Zero, LEDN) }
}

/* GpioInt — 인터럽트 리소스 예시 */
Device (BTNS) {
    Name (_HID, "MYBTN001")
    Name (_CRS, ResourceTemplate () {
        GpioInt (Edge, ActiveLow, SharedAndWake, PullUp, 0,
                 "\\_SB.GPO0", 0, ResourceConsumer, , ) { 15 }
    })
}

/* GenericSerialBus (I2C) Operation Region — 센서 읽기 */
Device (SNSR) {
    Name (_HID, "MYSN001")

    /* I2C 커넥션 리소스 */
    Name (_CRS, ResourceTemplate () {
        I2cSerialBusV2 (0x48,            /* 슬레이브 주소 */
                        ControllerInitiated,
                        400000,         /* 400 kHz */
                        AddressingMode7Bit,
                        "\\_SB.I2C1",   /* I2C 컨트롤러 */
                        0x00,
                        ResourceConsumer, , )
    })

    /* GenericSerialBus Operation Region */
    OperationRegion (I2CR, GenericSerialBus, 0, 0x100)
    Field (I2CR, BufferAcc, NoLock, Preserve) {
        Connection (I2cSerialBusV2 (0x48, ControllerInitiated,
                    400000, AddressingMode7Bit,
                    "\\_SB.I2C1", 0, , )),
        AccessAs (BufferAcc, AttribByte),
        TMPH, 8,     /* 온도 레지스터 (high byte) */
        TMPL, 8,     /* 온도 레지스터 (low byte) */
    }

    /* 온도 읽기 메서드 */
    Method (GTMP, 0, Serialized) {
        Local0 = TMPH
        Local1 = TMPL
        Return ((Local0 << 8) | Local1)
    }
}

ACPI 핫플러그

ACPI 핫플러그는 시스템 실행 중 디바이스(PCI, CPU, 메모리)의 추가/제거를 지원합니다. 펌웨어가 Notify 이벤트를 발생시키면 커널이 디바이스 열거/해제를 수행합니다.

PCI 핫플러그

/* PCI 핫플러그 — drivers/pci/hotplug/acpiphp_glue.c */

/* 핫플러그 Notify 핸들러 */
static void handle_hotplug_event(acpi_handle handle, u32 type, ...)
{
    switch (type) {
    case ACPI_NOTIFY_BUS_CHECK:         /* 0x00 */
    case ACPI_NOTIFY_DEVICE_CHECK:      /* 0x01 */
        /* _STA 평가: 디바이스 존재 여부 확인 */
        acpiphp_check_bridge(bridge);
        /* 새 디바이스 발견 → pci_scan_slot() → 드라이버 바인딩 */
        break;
    case ACPI_NOTIFY_EJECT_REQUEST:      /* 0x03 */
        /* _EJ0 메서드 실행 → 디바이스 제거 */
        acpiphp_disable_slot(slot);
        acpi_evaluate_ej0(handle);
        break;
    }
}

/* ASL 핫플러그 디바이스 정의 예시 */
/*
 * Device (SLT0) {
 *     Name (_ADR, 0x001F0000)
 *     Method (_STA, 0) { Return (0x0F) }  // Present + Enabled
 *     Method (_EJ0, 1) { ... }            // Eject 실행
 *     Method (_RMV, 0) { Return (1) }     // Removable
 * }
 */

PCIe Native Hotplug, AER, PME와 _OSC

서버와 워크스테이션에서 "핫플러그는 되는데 AER가 안 보인다" 또는 "PCIe 포트 서비스 드라이버가 안 붙는다"는 문제의 상당수는 _OSC 협상에서 이미 결정됩니다. _OSC는 Root Port 또는 Host Bridge가 펌웨어와 OS 사이에 PCIe 서비스 제어권을 나누는 메커니즘이며, Native Hotplug, PME, AER, SHPC 같은 권한을 OS가 얻어야 Linux 쪽 포트 서비스가 완전히 활성화됩니다.

# _OSC / PCIe 서비스 관련 단서 찾기
$ dmesg | grep -Ei "_OSC|AER|pciehp|PME|hotplug"

# Root Port capability와 서비스 드라이버 확인
$ lspci -vv -s 00:1c.0
$ lsmod | grep -E "pciehp|aer|pcieport"

# 강제로 OS 제어를 선호하도록 시도할 때 쓰는 커널 파라미터 예
# pcie_ports=native
# pcie_ports=compat

CPU / 메모리 핫플러그

/* CPU 핫플러그 — drivers/acpi/acpi_processor.c */
static void acpi_processor_hotplug_notify(struct acpi_device *adev, u32 type)
{
    switch (type) {
    case ACPI_NOTIFY_BUS_CHECK:
    case ACPI_NOTIFY_DEVICE_CHECK:
        /* CPU online: cpu_up() → sched_domain 재구성 */
        acpi_bus_scan(adev->handle);
        break;
    case ACPI_NOTIFY_EJECT_REQUEST:
        /* CPU offline: cpu_down() → 프로세스 마이그레이션 */
        acpi_scan_hot_remove(adev);
        break;
    }
}

/* 메모리 핫플러그 — drivers/acpi/acpi_memhotplug.c */
/* Notify 0x00 → acpi_memory_device_add()
 *             → add_memory_resource()
 *             → online_pages()
 *
 * sysfs로 메모리 블록 온라인:
 * echo online > /sys/devices/system/memory/memoryXX/state
 */

Container Device와 복합 핫플러그

ACPI Container Device는 CPU, 메모리, I/O 디바이스를 묶어 하나의 물리적 단위(소켓, NUMA 노드, 랙 블레이드)로 핫플러그하는 추상화입니다. ACPI 네임스페이스에서 \_SB.SCK0, \_SB.SCK1 같은 이름으로 나타나며, 서버 환경에서 CPU+메모리를 동시에 추가/제거하는 시나리오에 사용됩니다.

/* Container Device ASL 예시 — 소켓 단위 핫플러그 */
Device (SCK0) {
    Name (_HID, "ACPI0004")    /* Container Device HID */
    Name (_UID, 0)

    Method (_STA, 0) {
        If (SCKP) { Return (0x0F) }  /* Present + Enabled */
        Else      { Return (0x00) }  /* Not Present */
    }

    Method (_EJ0, 1) {
        /* 소켓 전원 차단 시퀀스 */
        Store (Zero, SCKP)
    }

    /* 소켓에 포함된 CPU들 */
    Processor (CP00, 0, 0, 0) {}
    Processor (CP01, 1, 0, 0) {}

    /* 소켓에 포함된 메모리 */
    Device (MEM0) {
        Name (_HID, "PNP0C80")   /* Memory Device */
        Name (_CRS, ResourceTemplate () {
            QWordMemory (ResourceProducer, , , , ,
                         0, 0x100000000, 0x13FFFFFFF, 0, 0x40000000)
        })
    }
}

/* Container 핫플러그 흐름 — drivers/acpi/container.c */

/* Container offline 시: 내부 디바이스를 역순으로 해제 */
/* 1. 자식 CPU들을 cpu_down() */
/* 2. 자식 메모리 블록을 offline_pages() */
/* 3. Container 자체를 acpi_scan_hot_remove() */
/* 4. _EJ0 실행으로 물리 전원 차단 */

/* QEMU에서 Container 핫플러그 테스트 */
/* qemu-system-x86_64 -machine q35,acpi=on \
 *   -smp 4,sockets=2,cores=2 \
 *   -m 4G,slots=4,maxmem=16G \
 *   -numa node,nodeid=0,cpus=0-1,memdev=m0 \
 *   -numa node,nodeid=1,cpus=2-3,memdev=m1
 */

핫플러그 디버깅

# ===== PCI 핫플러그 상태 확인 =====
$ ls /sys/bus/pci/slots/
$ cat /sys/bus/pci/slots/*/adapter
$ cat /sys/bus/pci/slots/*/power
$ cat /sys/bus/pci/slots/*/address

# PCIe 핫플러그 드라이버 로드 확인
$ lsmod | grep -E "pciehp|acpiphp|shpchp"
$ dmesg | grep -i "pciehp\|hotplug"

# ===== 메모리 핫플러그 상태 =====
$ cat /sys/devices/system/memory/memory*/state
$ cat /sys/devices/system/memory/block_size_bytes
# 메모리 블록 크기 (보통 128MB = 0x8000000)

# 메모리 블록 온라인/오프라인
$ echo online > /sys/devices/system/memory/memory64/state
$ echo offline > /sys/devices/system/memory/memory64/state

# 온라인 정책 변경 (zone_normal vs zone_movable)
$ echo online_movable > /sys/devices/system/memory/auto_online_blocks

# ===== CPU 핫플러그 =====
$ cat /sys/devices/system/cpu/cpu*/online
$ echo 0 > /sys/devices/system/cpu/cpu7/online
$ echo 1 > /sys/devices/system/cpu/cpu7/online
$ dmesg | grep -i "cpu.*online\|cpu.*offline\|smpboot"

# ===== 핫플러그 이벤트 모니터링 =====
$ acpi_listen
# device LNXSYSTM:00 00000088 00000000 (Bus Check)
# device PNP0A08:00 00000001 00000000 (Device Check)

$ dmesg -w | grep -iE "hotplug|acpi.*notify|eject|bus.check"

# ===== ACPI 핫플러그 sysfs 인터페이스 =====
$ cat /sys/firmware/acpi/hotplug/demand_offline
$ echo 1 > /sys/firmware/acpi/hotplug/demand_offline

커널 ACPI 서브시스템

drivers/acpi/ 디렉토리 구조

acpi_device 구조체

/* include/acpi/acpi_bus.h */
struct acpi_device {
    acpi_handle handle;              /* 네임스페이스 핸들 */
    struct device dev;               /* 리눅스 디바이스 모델 */

    struct acpi_device_status status; /* _STA 결과 */
    struct acpi_device_flags flags;

    struct acpi_hardware_id *pnp;    /* _HID, _CID, _UID */
    struct acpi_device_power power;  /* D-state 정보 */
    struct acpi_device_wakeup wakeup; /* 웨이크업 능력 */

    struct acpi_driver *driver;      /* 바인딩된 드라이버 */
    struct acpi_device *parent;      /* 부모 디바이스 */
    struct list_head children;       /* 자식 리스트 */
};

플랫폼 디바이스 연결 (ACPI_COMPANION)

/* ACPI 디바이스와 platform_device 연결 */
/* drivers/acpi/glue.c */

/* ACPI_COMPANION 매크로로 디바이스에서 acpi_device 접근 */
struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);

/* 드라이버에서 ACPI 매칭 테이블 정의 */
static const struct acpi_device_id my_acpi_ids[] = {
    { "PNP0C09", 0 },   /* Embedded Controller */
    { "ACPI0003", 0 },  /* AC Adapter */
    { "PNP0C0A", 0 },   /* Battery */
    { },
};
MODULE_DEVICE_TABLE(acpi, my_acpi_ids);

/* platform_driver에서 ACPI 매칭 사용 */
static struct platform_driver my_driver = {
    .driver = {
        .name = "my-acpi-device",
        .acpi_match_table = my_acpi_ids,
    },
    .probe = my_probe,
};

ACPI와 Device Tree를 어떻게 구분해 봐야 하는가

둘 다 "하드웨어를 OS에 기술한다"는 점은 같지만, 표현력과 실행 모델은 다릅니다. Device Tree는 정적 데이터 중심이고, ACPI는 데이터 테이블에 더해 AML 메서드와 런타임 조건 분기를 포함합니다. 드라이버 관점에서는 ACPI 지원을 추가할 때 DT 경로를 대체하는 것이 아니라, property / GPIO / interrupt 해석 계층을 공통화하는 방식이 일반적입니다.

ACPI Scan Handler 프레임워크

ACPI 디바이스 열거 과정에서 acpi_bus_scan()은 네임스페이스를 순회하며 각 디바이스 노드에 대해 등록된 Scan Handler를 호출합니다. Scan Handler는 특정 유형의 ACPI 디바이스(프로세서, 메모리, 컨테이너, 독 스테이션 등)를 커널 서브시스템에 연결하는 역할을 합니다.

/* include/acpi/acpi_bus.h */
struct acpi_scan_handler {
    const struct acpi_device_id *ids;  /* 매칭할 HID/CID 테이블 */

    /* 디바이스가 열거될 때 호출 */
    int (*attach)(struct acpi_device *adev,
                  const struct acpi_device_id *id);

    /* 디바이스가 제거될 때 호출 */
    void (*detach)(struct acpi_device *adev);

    /* 핫플러그 프로필 */
    struct acpi_hotplug_profile hotplug;

    struct list_head list_node;
};

/* Scan Handler 등록 흐름 */
/* 1. 부팅 초기에 acpi_scan_init()이 호출 */
/* 2. 각 서브시스템이 acpi_scan_add_handler()로 핸들러 등록 */
acpi_scan_add_handler(&processor_handler);
acpi_scan_add_handler(&memory_device_handler);
acpi_scan_add_handler(&container_handler);

/* 3. acpi_bus_scan()이 네임스페이스 순회 시:
 *    - 각 노드의 _HID를 모든 핸들러의 ids와 대조
 *    - 매칭되면 handler->attach() 호출
 *    - 매칭 실패 시 generic acpi_device로 등록
 */

ACPI 디바이스 드라이버 작성법

ACPI 전용 드라이버는 struct acpi_driver를 사용하여 ACPI 디바이스에 직접 바인딩합니다. 아래는 커스텀 ACPI 디바이스를 제어하는 완전한 드라이버 예시입니다.

/* 완전한 ACPI 디바이스 드라이버 예시 */
#include <linux/module.h>
#include <linux/acpi.h>

struct my_acpi_data {
    struct acpi_device *adev;
    unsigned long long current_state;
};

/* Notify 핸들러: 런타임 이벤트 수신 */
static void my_notify_handler(struct acpi_device *adev, u32 event)
{
    struct my_acpi_data *data = acpi_driver_data(adev);

    switch (event) {
    case 0x80:  /* 벤더 정의 이벤트 */
        dev_info(&adev->dev, "상태 변경 이벤트 수신\n");
        acpi_evaluate_integer(adev->handle, "_STA",
                              NULL, &data->current_state);
        break;
    default:
        dev_dbg(&adev->dev, "알 수 없는 이벤트: 0x%02x\n", event);
    }
}

/* 디바이스 추가 콜백 */
static int my_acpi_add(struct acpi_device *adev)
{
    struct my_acpi_data *data;
    acpi_status status;
    unsigned long long sta;

    /* _STA 평가: 디바이스 존재 확인 */
    status = acpi_evaluate_integer(adev->handle, "_STA", NULL, &sta);
    if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
        return -ENODEV;

    data = devm_kzalloc(&adev->dev, sizeof(*data), GFP_KERNEL);
    if (!data)
        return -ENOMEM;

    data->adev = adev;
    data->current_state = sta;
    adev->driver_data = data;

    dev_info(&adev->dev, "ACPI 디바이스 %s 추가 (STA=0x%llx)\n",
             acpi_device_hid(adev), sta);
    return 0;
}

/* 디바이스 제거 콜백 */
static void my_acpi_remove(struct acpi_device *adev)
{
    dev_info(&adev->dev, "ACPI 디바이스 %s 제거\n",
             acpi_device_hid(adev));
}

/* 매칭 테이블 */
static const struct acpi_device_id my_acpi_ids[] = {
    { "MYDEV001", 0 },
    { "PNP0C0D", 0 },   /* Lid switch */
    { },
};
MODULE_DEVICE_TABLE(acpi, my_acpi_ids);

static struct acpi_driver my_acpi_driver = {
    .name  = "my_acpi",
    .class = "my_acpi_class",
    .ids   = my_acpi_ids,
    .ops   = {
        .add    = my_acpi_add,
        .remove = my_acpi_remove,
        .notify = my_notify_handler,
    },
};
module_acpi_driver(my_acpi_driver);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Example ACPI device driver");

ACPI 리소스 파싱 (_CRS 디코딩)

ACPI 디바이스의 _CRS(Current Resource Settings) 메서드는 디바이스가 사용하는 하드웨어 리소스(메모리, I/O 포트, IRQ, DMA, GPIO, 직렬 버스)를 기술합니다. 커널의 acpi_dev_get_resources() API로 이 정보를 파싱하여 struct resource로 변환합니다.

/* _CRS 리소스 파싱 콜백 패턴 */
static int my_resource_cb(struct acpi_resource *ares, void *data)
{
    struct resource r;

    /* 메모리 리소스 */
    if (acpi_dev_resource_memory(ares, &r)) {
        pr_info("Memory: %pR\n", &r);
        return 0;
    }

    /* I/O 포트 리소스 */
    if (acpi_dev_resource_io(ares, &r)) {
        pr_info("IO Port: %pR\n", &r);
        return 0;
    }

    /* 인터럽트 리소스 */
    if (acpi_dev_resource_interrupt(ares, 0, &r)) {
        pr_info("IRQ: %pR\n", &r);
        return 0;
    }

    /* GPIO 리소스 */
    if (ares->type == ACPI_RESOURCE_TYPE_GPIO) {
        struct acpi_resource_gpio *gpio = &ares->data.gpio;
        pr_info("GPIO: pin=%u type=%s\n",
                gpio->pin_table[0],
                gpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT
                    ? "interrupt" : "io");
        return 0;
    }

    /* I2C SerialBus 리소스 */
    if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS &&
        ares->data.common_serial_bus.type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
        struct acpi_resource_i2c_serialbus *i2c;
        i2c = &ares->data.i2c_serial_bus;
        pr_info("I2C: addr=0x%04x speed=%uHz\n",
                i2c->slave_address, i2c->connection_speed);
        return 0;
    }

    return 0;  /* 0: 계속 / 1: 중단 */
}

/* 드라이버 probe에서 리소스 파싱 */
struct list_head resource_list;
INIT_LIST_HEAD(&resource_list);

acpi_dev_get_resources(adev, &resource_list, my_resource_cb, NULL);
acpi_dev_free_resource_list(&resource_list);

디버깅 & 트러블슈팅

acpi.debug_layer / acpi.debug_level

# ACPI 디버그 레이어/레벨 활성화 (커널 CONFIG_ACPI_DEBUG=y 필요)

# 디버그 레이어 — 서브시스템별 필터링
$ echo 0xFFFFFFFF > /sys/module/acpi/parameters/debug_layer
# 주요 레이어:
# 0x00000001 = ACPI_UTILITIES     0x00000010 = ACPI_TABLES
# 0x00000020 = ACPI_EVENTS        0x00000040 = ACPI_CONTROL_METHODS
# 0x00000100 = ACPI_NAMESPACE     0x00000800 = ACPI_BUS_COMPONENT

# 디버그 레벨 — 상세도 조절
$ echo 0x0000001F > /sys/module/acpi/parameters/debug_level
# 0x01 = Error  0x02 = Warn  0x04 = Info  0x08 = Debug  0x10 = Verbose

# 부팅 시 커널 파라미터로 설정
# acpi.debug_layer=0x20 acpi.debug_level=0x1F

/sys/firmware/acpi/ 인터페이스

# ACPI 테이블 원본 덤프
$ ls /sys/firmware/acpi/tables/
APIC  DSDT  FACP  FACS  HMAT  MCFG  SRAT  SSDT*

# DSDT 디컴파일 (iasl 필요)
$ cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
$ iasl -d dsdt.aml    # → dsdt.dsl (ASL 소스)

# ACPI 이벤트 인터럽트 카운터
$ cat /sys/firmware/acpi/interrupts/sci
$ cat /sys/firmware/acpi/interrupts/gpe_all

# PM 프로필
$ cat /sys/firmware/acpi/pm_profile
Desktop

acpidump / acpixtract / iasl 실전 절차

복잡한 플랫폼에서는 DSDT 하나만 디컴파일하면 참조가 끊기기 쉽습니다. SSDT가 여러 장 겹쳐 장치 정의를 덮어쓰는 경우가 흔하므로, 가능하면 전체 테이블을 덤프(Dump)하고 외부 참조를 포함해 디컴파일하는 편이 정확합니다.

# 1) 전체 ACPI 테이블 덤프 (acpica-tools 필요)
$ acpidump -b

# 2) 바이너리 테이블 분해
$ acpixtract -a acpidump.out

# 3) SSDT들을 외부 참조로 포함하여 DSDT 디컴파일
$ iasl -e ssdt*.dat -d dsdt.dat

# 4) 관심 장치/메서드 찾기
$ grep -n "Device (EC0)" dsdt.dsl
$ grep -n "_PRW" dsdt.dsl
$ grep -n "OperationRegion" dsdt.dsl
$ grep -n "_OSC" dsdt.dsl

DSDT/SSDT를 읽는 실제 패턴

디컴파일된 ASL을 처음 보면 "문법은 읽히는데 어디서부터 봐야 하는지"가 가장 어렵습니다. 실전에서는 전체 파일을 위에서 아래로 읽기보다, 문제가 난 장치의 ACPI 경로를 잡고 그 장치를 둘러싼 식별, 자원, wake, power method를 역으로 추적하는 방식이 효율적입니다.

/* SSDT/DSDT에서 자주 보는 문제 장치 예시 */
Device (XHCI) {
    Name (_ADR, 0x00140000)
    Name (_STA, 0x0F)
    Method (_CRS, 0, Serialized) { ... }
    Method (_PRW, 0, NotSerialized) {
        Return (Package () { 0x6D, 0x03 })
    }
    Name (_PR0, Package () { PR2A })
    Name (_PR3, Package () { PR3A })
    Method (_PS0, 0) { ... }
    Method (_PS3, 0) { ... }
}

ACPI 커널 파라미터 총정리

ACPI 테이블 오버라이드 (Custom DSDT)

펌웨어 DSDT에 버그가 있을 때, BIOS 업데이트 없이 커스텀 DSDT로 교체하여 문제를 우회할 수 있습니다. 리눅스 커널은 initrd를 통한 ACPI 테이블 오버라이드를 지원합니다.

# 1. 현재 DSDT 추출
$ cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

# 2. 디컴파일 (SSDT 외부 참조 포함)
$ acpidump -b
$ acpixtract -a acpidump.out
$ iasl -e ssdt*.dat -d dsdt.dat    # → dsdt.dsl

# 3. ASL 소스 수정 (예: 문제 메서드 패치)
$ vi dsdt.dsl
# 수정 예: _OSI 조건 추가, _STA 반환값 변경, _CRS 리소스 수정 등

# 4. 재컴파일
$ iasl dsdt.dsl               # → dsdt.aml (에러 없이 빌드되는지 확인)

# 5. initrd CPIO 아카이브 생성
$ mkdir -p kernel/firmware/acpi
$ cp dsdt.aml kernel/firmware/acpi/
$ find kernel | cpio -H newc --create > /boot/acpi_override.cpio

# 6. GRUB 설정 (grub.cfg 또는 /etc/default/grub)
# initrd /boot/acpi_override.cpio /boot/initramfs-$(uname -r).img
# 주의: acpi_override.cpio가 반드시 먼저 와야 합니다

# 7. 재부팅 후 오버라이드 확인
$ dmesg | grep -i "ACPI.*override\|ACPI.*upgrade"
# [    0.000000] ACPI: Table Upgrade: override [DSDT- ...]

흔한 ACPI 문제와 해결법

ACPI 디버깅 플레이북

ACPI 문제는 BIOS/펌웨어 AML 품질의 영향을 크게 받기 때문에, 커널 코드만 보는 방식으로는 해결이 어렵습니다. 테이블 원본, AML 디컴파일 결과, 런타임 이벤트를 함께 비교해야 합니다.

# DSDT 추출 및 디컴파일
cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
iasl -d dsdt.aml

# ACPI 디버그 레벨 상승
echo 0xFFFFFFFF > /sys/module/acpi/parameters/debug_layer
echo 0x1F > /sys/module/acpi/parameters/debug_level

# 이벤트 카운터 점검
cat /sys/firmware/acpi/interrupts/gpe_all
cat /sys/firmware/acpi/interrupts/sci

Suspend/Resume 디버깅 플레이북

Suspend/Resume 실패는 ACPI 문제 중 가장 빈번하며, 원인이 펌웨어 AML, 드라이버, 디바이스 전원 순서에 걸쳐 분산됩니다. 단계별 격리(Isolation)가 핵심입니다.

# 1단계: 어느 phase에서 실패하는지 확인
$ echo devices > /sys/power/pm_test
$ echo mem > /sys/power/state      # devices freeze까지만 실행
$ dmesg | tail -50

# pm_test 값: none, core, processors, platform, devices, freezer
# 각 단계를 순서대로 테스트하면 실패 지점이 좁혀집니다

# 2단계: 어떤 디바이스에서 멈추는지 확인
$ echo 1 > /sys/power/pm_print_times
$ echo mem > /sys/power/state
$ dmesg | grep -E "call |suspend |resume " | sort -k3 -t'[' -n

# 3단계: 특정 디바이스 격리 (runtime PM 비활성화)
$ echo on > /sys/devices/pci0000:00/0000:00:1f.3/power/control

# 4단계: ACPI wakeup 소스 점검
$ cat /proc/acpi/wakeup
# Device  S-state  Status   Sysfs node
# XHCI      S3    *enabled  pci:0000:00:14.0

# 불필요한 wakeup 소스 비활성화
$ echo XHCI > /proc/acpi/wakeup     # 토글

# 5단계: 콘솔 유지하며 suspend (직렬 콘솔 필요)
# 커널 파라미터: no_console_suspend

GPE Storm 진단과 해결

GPE storm은 특정 GPE가 초당 수천 번 발생하여 시스템 성능을 심각하게 저하시키는 현상입니다. 커널은 자동으로 폭주 GPE를 감지하고 비활성화하지만, 근본 원인을 찾아야 합니다.

# GPE 발생 횟수 확인
$ cat /sys/firmware/acpi/interrupts/gpe_all
$ cat /sys/firmware/acpi/interrupts/gpe00
$ cat /sys/firmware/acpi/interrupts/gpe17    # 의심되는 GPE 번호

# GPE storm 감지 로그
$ dmesg | grep -i "GPE.*disabled\|flood"

# 특정 GPE 수동 비활성화/활성화
$ echo disable > /sys/firmware/acpi/interrupts/gpe17
$ echo enable > /sys/firmware/acpi/interrupts/gpe17
$ echo clear > /sys/firmware/acpi/interrupts/gpe17

# GPE와 연결된 디바이스 찾기 (DSDT에서)
# _PRW(Package(){0x11, 0x03}) → GPE 0x11 = GPE17
$ grep -n "_PRW\|_Lxx\|_Exx" dsdt.dsl | grep -i "17\|0x11"

# EC GPE 확인 (보통 EC의 GPE가 폭주 원인)
$ cat /sys/firmware/acpi/interrupts/sci

EC 통신 디버깅 체크리스트

# EC 상태 확인
$ cat /sys/kernel/debug/ec/ec0/io
# command: 0x00  status: 0x08 (IBF=0, OBF=1, ...)

# EC 트랜잭션 추적
$ echo 1 > /sys/module/acpi/parameters/ec_debug
$ dmesg -w | grep EC

# EC GPE 번호 확인
$ cat /sys/kernel/debug/ec/ec0/gpe
# 보통 0x16 또는 0x50 — FADT의 EC GPE와 일치해야 함

# EC 응답 타임아웃 조정
# 커널 파라미터: acpi.ec_delay=200 (마이크로초)
# 커널 파라미터: acpi.ec_busy_polling (폴링 모드 전환)

# EC 이벤트 모니터링
$ acpi_listen
# battery BAT0 00000080 00000001
# ac_adapter ACAD 00000080 00000001
# button/lid LID 00000080 00000001

acpidump/acpixtract 실전

ACPI 테이블 디버깅의 첫 단계는 펌웨어가 메모리에 배치한 원시 테이블을 덤프하는 것입니다. acpidump는 /sys/firmware/acpi/tables/ 또는 /dev/mem을 통해 모든 ACPI 테이블을 16진수로 추출하고, acpixtract는 이 덤프에서 개별 테이블을 바이너리 파일로 분리합니다.

전체 테이블 덤프

# 전체 ACPI 테이블을 하나의 텍스트 파일로 덤프
$ sudo acpidump > acpi_tables.dat

# 바이너리 형태로 덤프 (iasl에서 바로 사용 가능)
$ sudo acpidump -b
# → dsdt.dat, facp.dat, apic.dat, ... 개별 바이너리 생성

# 특정 테이블만 추출
$ sudo acpidump -n DSDT > dsdt_hex.dat
$ sudo acpidump -n MADT > madt_hex.dat

# sysfs에서 직접 읽기 (acpidump 없을 때)
$ sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
$ ls /sys/firmware/acpi/tables/
# APIC  BGRT  DSDT  FACP  FACS  HPET  MCFG  SRAT  SSDT1  SSDT2  ...

개별 테이블 분리

# acpidump 출력에서 개별 바이너리 추출
$ acpixtract -a acpi_tables.dat
# → dsdt.dat, facp.dat, apic.dat, ssdt1.dat, ssdt2.dat, ... 생성

# 특정 테이블만 추출
$ acpixtract -sDSDT acpi_tables.dat
# → dsdt.dat

# SSDT가 여러 개인 경우 인덱스로 선택
$ acpixtract -sSSDT acpi_tables.dat
# → ssdt1.dat, ssdt2.dat, ssdt3.dat, ...

# 추출된 파일 목록 확인
$ acpixtract -l acpi_tables.dat
# DSDT   62731  dsdt.dat
# FACP     276  facp.dat
# APIC     188  apic.dat
# MCFG      60  mcfg.dat

hexdump 분석

# 바이너리 테이블의 헤더 36바이트 분석
$ hexdump -C dsdt.dat | head -3
# 00000000  44 53 44 54  xx xx xx xx  02  xx xx xx xx  ...
#           ^Signature   ^Length       ^Rev ^OEM ID

# ACPI 테이블 공통 헤더 구조 (36바이트)
# Offset  Size  Field
# 0x00    4     Signature ("DSDT", "FACP", "APIC" 등)
# 0x04    4     Length (헤더 포함 전체 길이)
# 0x08    1     Revision
# 0x09    1     Checksum
# 0x0A    6     OEM ID
# 0x10    8     OEM Table ID
# 0x18    4     OEM Revision
# 0x1C    4     Creator ID (보통 "INTL" = iasl)
# 0x20    4     Creator Revision

# xxd로 특정 오프셋 분석
$ xxd -s 0x24 -l 64 dsdt.dat
# → AML 바이트코드 시작 부분

바이너리 비교 스크립트

#!/bin/bash
# BIOS 업데이트 전후 ACPI 테이블 변경 확인
# 사전: mkdir before after

compare_tables() {
    local dir1="$1" dir2="$2"
    echo "=== ACPI 테이블 변경 비교 ==="

    # 테이블별 바이너리 비교
    for f in "$dir1"/*.dat; do
        name=$(basename "$f")
        if [ -f "$dir2/$name" ]; then
            if ! cmp -s "$f" "$dir2/$name"; then
                echo "[변경] $name"
                # iasl로 디컴파일 후 텍스트 비교
                iasl -d "$f" 2>/dev/null
                iasl -d "$dir2/$name" 2>/dev/null
                diff -u "${f%.dat}.dsl" "${dir2}/${name%.dat}.dsl"
            else
                echo "[동일] $name"
            fi
        else
            echo "[신규] $name (이전 버전에 없음)"
        fi
    done
}

compare_tables before after

테이블별 acpidump 출력 해석

iasl 디컴파일과 AML 분석

iasl(iASL Compiler/Disassembler)은 ACPICA 프로젝트의 핵심 도구로, ASL(ACPI Source Language) 소스를 AML(ACPI Machine Language) 바이너리로 컴파일하거나, 반대로 AML을 다시 ASL로 디컴파일하는 양방향 변환기입니다. 펌웨어 벤더가 작성한 DSDT/SSDT의 동작을 이해하고 버그를 추적하는 데 필수적인 도구입니다.

DSDT 디컴파일

# DSDT 바이너리 추출 후 디컴파일
$ sudo acpidump -b -n DSDT
$ iasl -d dsdt.dat
# → dsdt.dsl 생성 (ASL 소스)

# 외부 참조 해결을 위해 SSDT도 함께 디컴파일
$ sudo acpidump -b
$ iasl -d -e ssdt*.dat dsdt.dat
# -e: External reference 파일 지정
# → SSDT에 정의된 심볼 참조가 정상 해석됨

# 디컴파일 결과 확인
$ head -20 dsdt.dsl
# DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I", 0x01072009)
# {
#     External (\_SB.PCI0.LPCB.EC0, DeviceObj)
#     ...

디컴파일된 ASL 분석

/* 디컴파일된 ASL 예시: 배터리 장치 */
Device (BAT0)
{
    Name (_HID, EisaId ("PNP0C0A"))  /* Control Method Battery */
    Name (_UID, 0)

    Method (_STA, 0, NotSerialized)   /* 장치 존재 여부 */
    {
        If (ECAV ())    /* EC 사용 가능? */
        {
            If (BSLF)      /* Battery Slot Flag */
            {
                Return (0x1F)  /* Present + Enabled + Functioning */
            }
        }
        Return (0x00)
    }

    Method (_BIF, 0, NotSerialized)   /* Battery Info (정적) */
    {
        Name (BPKG, Package (13)
        {
            0x01,       /* Power Unit: mAh */
            0x1770,     /* Design Capacity: 6000 mAh */
            0x1770,     /* Last Full Charge Capacity */
            0x01,       /* Rechargeable */
            0x39D0,     /* Design Voltage: 14800 mV */
            /* ... */
        })
        Return (BPKG)
    }
}

iasl 컴파일과 오류 수정

# 디컴파일된 ASL 재컴파일 (오류 확인)
$ iasl dsdt.dsl
# 경고/오류 출력 예:
# dsdt.dsl  1234:  Warning 3107 - Use of compiler reserved name  [_T_0]
# dsdt.dsl  5678:  Error   6126 - Duplicate object created  [PEGP]

# 일반적인 수정 패턴
# 1) _T_0 경고: ACPICA 내부 변수명 충돌 — 이름 변경
# 2) 중복 정의: External() 선언과 실제 정의 충돌 — External() 제거
# 3) Zero → Package() 누락 인자 — 0을 삽입

# 수정 후 재컴파일
$ iasl -f dsdt_fixed.dsl
# -f: 경고 무시하고 강제 컴파일
# → dsdt_fixed.aml 생성

# 커스텀 DSDT 적용 (GRUB)
# /etc/grub.d/40_custom에 추가:
# acpi /boot/dsdt_fixed.aml

SSDT 작성 예제

/* 커스텀 SSDT: GPIO LED 제어 장치 추가 */
DefinitionBlock ("ssdt-led.aml", "SSDT", 2,
                 "CUSTOM", "LEDCTRL", 0x00000001)
{
    External (\_SB.PCI0.LPCB, DeviceObj)

    Scope (\_SB.PCI0.LPCB)
    {
        Device (CLED)
        {
            Name (_HID, "CUST0001")
            Name (_CID, "PNP0A06")  /* Generic Container */

            Method (_STA, 0, NotSerialized)
            {
                Return (0x0F)  /* Present, Enabled */
            }

            /* GPIO 리소스: GPIO 핀 47 */
            Name (_CRS, ResourceTemplate ()
            {
                GpioIo (Exclusive, PullDefault, 0x0000,
                        0x0000, IoRestrictionOutputOnly,
                        "\\_SB.PCI0.GPIO", 0x00,
                        ResourceConsumer, , )
                {
                    47
                }
            })

            /* LED ON/OFF 제어 메서드 */
            Method (LEDC, 1, Serialized)
            {
                /* Arg0: 0=OFF, 1=ON */
            }
        }
    }
}

AML 디버거(acpi_dbg) 사용법

# 커널 AML 디버거 활성화
# CONFIG_ACPI_DEBUGGER=y, CONFIG_ACPI_DEBUGGER_USER=m
$ sudo modprobe acpi_dbg

# AML 디버거 연결
$ sudo cat /sys/kernel/debug/acpi/acpidbg &
$ sudo echo "help" > /sys/kernel/debug/acpi/acpidbg

# 네임스페이스 탐색
$ echo "namespace" > /sys/kernel/debug/acpi/acpidbg
# → \_SB.PCI0 — Device
# → \_SB.PCI0.LPCB — Device
# → \_SB.PCI0.LPCB.EC0 — Device

# 특정 메서드 실행
$ echo "execute \_SB.PCI0.LPCB.EC0._STA" > /sys/kernel/debug/acpi/acpidbg
# → Evaluation of \_SB.PCI0.LPCB.EC0._STA returned 0x0F

# 객체 내용 확인
$ echo "dump \_SB.PCI0.LPCB.EC0._CRS" > /sys/kernel/debug/acpi/acpidbg

# 브레이크포인트 설정
$ echo "set method \_SB.BAT0._BST" > /sys/kernel/debug/acpi/acpidbg
# → _BST 호출 시 AML 실행 단계별 추적 가능

_DSM 메서드

_DSM(Device Specific Method)은 ACPI 네임스페이스의 표준 메서드 이름이지만, 그 내용은 벤더가 자유롭게 정의합니다. UUID로 기능 집합을 구분하고, Function Index로 개별 기능을 선택하는 확장 가능한 구조를 가집니다. GPIO 컨트롤러, Thunderbolt, NVMe, USB Type-C 등 다양한 하드웨어에서 OS-벤더 간 사적 계약을 맺는 핵심 메커니즘입니다.

_DSM ASL 구현 예

/* GPIO 컨트롤러 _DSM 구현 예 */
Method (_DSM, 4, Serialized)
{
    /* Arg0: UUID, Arg1: Revision, Arg2: Function Index, Arg3: Arguments */

    /* UUID 확인: GPIO Controller */
    If (LEqual (Arg0, ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")))
    {
        Switch (ToInteger (Arg2))
        {
            /* Function 0: 지원 함수 비트마스크 */
            Case (0)
            {
                Return (Buffer (1) { 0x0F })  /* Func 0-3 지원 */
            }
            /* Function 1: GPIO 핀 수 반환 */
            Case (1)
            {
                Return (0x08)  /* 8개 핀 */
            }
            /* Function 2: 핀 매핑 테이블 */
            Case (2)
            {
                Return (Package () {
                    0x00, 0x01, 0x02, 0x03,
                    0x04, 0x05, 0x06, 0x07
                })
            }
            /* Function 3: Active Low/High 속성 */
            Case (3)
            {
                Return (Buffer (1) { 0x00 })
            }
        }
    }

    /* 알 수 없는 UUID → 빈 버퍼 */
    Return (Buffer (1) { 0x00 })
}

acpi_evaluate_dsm 커널 API

/* 커널 드라이버에서 _DSM 호출 */
union acpi_object *obj;
static const guid_t gpio_dsm_guid =
    GUID_INIT(0xdaffd814, 0x6eba, 0x4d8c,
              0x8a, 0x91, 0xbc, 0x9b,
              0xbf, 0x4a, 0xa3, 0x01);

/* Function 0: 지원 기능 확인 */
if (!acpi_check_dsm(handle, &gpio_dsm_guid, 0, BIT(1) | BIT(2))) {
    dev_err(dev, "_DSM function 1,2 not supported\n");
    return -ENODEV;
}

/* Function 1 호출: GPIO 핀 수 */
obj = acpi_evaluate_dsm(handle, &gpio_dsm_guid,
                        0,   /* revision */
                        1,   /* function index */
                        NULL /* arguments */);
if (obj && obj->type == ACPI_TYPE_INTEGER) {
    nr_pins = obj->integer.value;
    dev_info(dev, "GPIO controller has %llu pins\n", nr_pins);
}
ACPI_FREE(obj);

/* Function 2 호출: 핀 매핑 (Package 결과) */
obj = acpi_evaluate_dsm_typed(handle, &gpio_dsm_guid,
                               0, 2, NULL,
                               ACPI_TYPE_PACKAGE);
if (obj) {
    for (i = 0; i < obj->package.count; i++) {
        pin_map[i] = obj->package.elements[i].integer.value;
    }
    ACPI_FREE(obj);
}

실제 사용되는 주요 _DSM UUID

Thermal Zone AML

ACPI Thermal Zone은 펌웨어가 열 관리 정책을 AML 메서드로 정의하는 메커니즘입니다. 커널의 acpi_thermal 드라이버가 이 메서드들을 주기적으로 실행해 현재 온도를 읽고, 임계값을 비교하며, 능동/수동 냉각 동작을 결정합니다. 여기서는 실제 ASL 코드와 커널 파싱 로직을 함께 분석합니다.

ThermalZone ASL 정의

/* 전형적인 ThermalZone ASL 정의 */
ThermalZone (TZ00)
{
    /* 현재 온도 (단위: 1/10 켈빈) */
    Method (_TMP, 0, Serialized)
    {
        If (ECAV ())    /* EC 사용 가능 여부 */
        {
            Local0 = \_SB.PCI0.LPCB.EC0.CTMP  /* EC에서 온도 읽기 */
            /* 섭씨 → 1/10 켈빈 변환 */
            Local0 = (Local0 * 10) + 2732
            Return (Local0)
        }
        Return (3000)   /* 폴백: 27°C = 3002 → 반올림 3000 */
    }

    /* 수동 냉각 임계값: 85°C */
    Method (_PSV, 0, NotSerialized)
    {
        Return (3582)   /* (85 * 10) + 2732 = 3582 */
    }

    /* 능동 냉각 임계값 레벨 0 (최저 온도 → 팬 최대): 70°C */
    Method (_AC0, 0, NotSerialized)
    {
        Return (3432)   /* (70 * 10) + 2732 = 3432 */
    }

    /* 능동 냉각 레벨 1 (팬 중속): 60°C */
    Method (_AC1, 0, NotSerialized)
    {
        Return (3332)   /* (60 * 10) + 2732 */
    }

    /* 크리티컬 온도: 100°C → 시스템 종료 */
    Method (_CRT, 0, NotSerialized)
    {
        Return (3732)   /* (100 * 10) + 2732 = 3732 */
    }

    /* 폴링 주기: 3초 (1/10초 단위) */
    Name (_TZP, 30)

    /* 수동 냉각 제어 계수 */
    Name (_TC1, 4)    /* 현재 온도 가중치 */
    Name (_TC2, 3)    /* 이전 온도 가중치 */
    Name (_TSP, 50)   /* 샘플링 주기: 5초 */
}

_PSL(Passive List) 구현

/* _PSL: 수동 냉각 대상 프로세서 목록 */
Method (_PSL, 0, NotSerialized)
{
    /* CPU 코어 0~3을 스로틀링 대상으로 지정 */
    Return (Package () {
        \_SB.PR00,  /* CPU 코어 0 */
        \_SB.PR01,  /* CPU 코어 1 */
        \_SB.PR02,  /* CPU 코어 2 */
        \_SB.PR03   /* CPU 코어 3 */
    })
}

/* _AL0: 능동 냉각 레벨 0 장치 목록 (팬) */
Method (_AL0, 0, NotSerialized)
{
    Return (Package (1) { FAN0 })
}

/* FAN0 장치: _FST(Fan Status)/_FSL(Fan Speed Level) */
Device (FAN0)
{
    Name (_HID, EisaId ("PNP0C0B"))   /* Fan */
    Name (_UID, 0)

    Method (_STA, 0, NotSerialized) { Return (0x0F) }

    /* _SCP: 냉각 정책 설정 */
    /* Arg0: 0 = Active, 1 = Passive */
    Method (_SCP, 1, NotSerialized)
    {
        If (LEqual (Arg0, 0))
        {
            /* Active 모드: 팬 ON */
            \_SB.PCI0.LPCB.EC0.FANC = 1
        }
        Else
        {
            /* Passive 모드: 팬 OFF, CPU 스로틀 */
            \_SB.PCI0.LPCB.EC0.FANC = 0
        }
    }
}

커널 acpi_thermal_zone 파싱

/* drivers/acpi/thermal.c — Thermal Zone 등록 흐름 */

/* 1. 트립 포인트 읽기 */
static int acpi_thermal_trips_update(struct acpi_thermal *tz, int flag)
{
    /* _CRT 임계값 읽기 */
    status = acpi_evaluate_integer(tz->device->handle,
                                   "_CRT", NULL, &tmp);
    if (ACPI_SUCCESS(status)) {
        tz->trips.critical.temperature = tmp;
        tz->trips.critical.valid = true;
    }

    /* _PSV 임계값 읽기 */
    status = acpi_evaluate_integer(tz->device->handle,
                                   "_PSV", NULL, &tmp);
    if (ACPI_SUCCESS(status)) {
        tz->trips.passive.temperature = tmp;
        tz->trips.passive.valid = true;
    }

    /* _AC0~_AC9 능동 냉각 임계값 */
    for (i = 0; i < ACPI_THERMAL_MAX_ACTIVE; i++) {
        char name[] = "_AC0";
        name[3] = '0' + i;
        status = acpi_evaluate_integer(tz->device->handle,
                                       name, NULL, &tmp);
        if (ACPI_FAILURE(status))
            break;
        tz->trips.active[i].temperature = tmp;
        tz->trips.active[i].valid = true;
    }

    return 0;
}

/* 2. thermal_zone_device 등록 */
/* → /sys/class/thermal/thermal_zone0/ 생성 */
/* → temp, trip_point_0_temp, trip_point_0_type 등 sysfs 노출 */

/* 3. 온도 폴링 (커널 타이머) */
/* _TZP 값 → polling_frequency 설정 */
/* 타이머 만료 시 _TMP 호출 → 임계값 비교 → 냉각 동작 */

SSDT 오버레이 (런타임 테이블 로드)

리눅스 커널은 부팅 후에도 SSDT(Secondary System Description Table)를 동적으로 로드할 수 있는 메커니즘을 제공합니다. 이를 통해 펌웨어에 없는 장치를 추가하거나, 기존 DSDT의 버그를 우회하거나, 프로토타입 하드웨어를 테스트할 수 있습니다. configfs 인터페이스와 initrd 기반 로드 두 가지 방법이 있습니다.

SSDT ASL 작성

/* 커스텀 SSDT: I2C 센서 장치 추가 */
DefinitionBlock ("ssdt-sensor.aml", "SSDT", 2,
                 "CUSTOM", "SENSOR", 0x00000001)
{
    External (\_SB.PCI0.I2C1, DeviceObj)

    Scope (\_SB.PCI0.I2C1)
    {
        Device (TSN0)
        {
            Name (_HID, "TXNW0001")
            Name (_UID, 0)

            Method (_STA, 0, NotSerialized)
            {
                Return (0x0F)
            }

            Name (_CRS, ResourceTemplate ()
            {
                I2cSerialBusV2 (0x48,
                    ControllerInitiated,
                    400000,  /* 400 kHz */
                    AddressingMode7Bit,
                    "\\_SB.PCI0.I2C1",
                    0x00,
                    ResourceConsumer, , Exclusive, )
                GpioInt (Level, ActiveLow, ExclusiveAndWake,
                         PullDefault, 0x0000,
                         "\\_SB.PCI0.GPIO", 0x00,
                         ResourceConsumer, , )
                {
                    27  /* GPIO 27: 인터럽트 핀 */
                }
            })
        }
    }
}

iasl 컴파일과 configfs 로드

# 1. ASL → AML 컴파일
$ iasl ssdt-sensor.dsl
# → ssdt-sensor.aml 생성

# 2. configfs를 통한 런타임 로드
# CONFIG_ACPI_CONFIGFS=m 필요
$ sudo modprobe acpi_configfs
$ sudo mkdir /sys/kernel/config/acpi/table/sensor0

# AML 바이너리를 configfs에 기록
$ sudo cp ssdt-sensor.aml /sys/kernel/config/acpi/table/sensor0/aml

# 3. 로드 확인
$ dmesg | tail -5
# [  xxx] ACPI: Host-directed Dynamic ACPI Table Load:
# [  xxx] ACPI: SSDT 0xFFFF... 000090 (v02 CUSTOM SENSOR   00000001 INTL 20200925)
# [  xxx] ACPI: \_SB.PCI0.I2C1.TSN0: Device present

# 4. 장치 확인
$ ls /sys/bus/acpi/devices/ | grep TSN
# TXNW0001:00

# 5. 오버레이 제거 (언로드)
$ sudo rmdir /sys/kernel/config/acpi/table/sensor0
$ dmesg | tail -2
# [  xxx] ACPI: Host-directed Dynamic ACPI Table Unload

configfs를 통한 로드 상세

/* drivers/acpi/acpi_configfs.c — configfs 핸들러 */

/* AML 데이터 쓰기 콜백 */
static ssize_t acpi_table_aml_write(
    struct config_item *cfg,
    const void *data, size_t size)
{
    /* 테이블 시그니처 검증 */
    header = (struct acpi_table_header *)data;
    if (header->length != size)
        return -EINVAL;

    /* ACPICA에 테이블 설치 */
    status = acpi_install_table(data, ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL);
    if (ACPI_FAILURE(status))
        return -EINVAL;

    /* 새로 추가된 네임스페이스 노드 스캔 */
    acpi_load_table(tbl_index, &handle);
    acpi_bus_scan(handle);

    return size;
}

initrd 내 SSDT 로드

# initrd에 SSDT를 포함시켜 부팅 시 자동 로드
# 커널 옵션: CONFIG_ACPI_TABLE_UPGRADE=y

# 1. 디렉토리 구조 생성
$ mkdir -p kernel/firmware/acpi

# 2. AML 파일 복사
$ cp ssdt-sensor.aml kernel/firmware/acpi/

# 3. CPIO 아카이브 생성 (비압축)
$ find kernel | cpio -H newc --create > ssdt-initrd.img

# 4. 기존 initrd 앞에 결합
$ cat ssdt-initrd.img /boot/initrd.img-$(uname -r) > /boot/initrd-combined.img

# 5. GRUB 설정 업데이트
# /etc/grub.d/40_custom 또는 /boot/grub/grub.cfg 수정
# initrd /boot/initrd-combined.img
$ sudo update-grub

# 6. 재부팅 후 확인
$ dmesg | grep "ACPI.*SSDT.*CUSTOM"
# [    0.xxx] ACPI: SSDT 0xFFFF... (v02 CUSTOM SENSOR ...)
# [    0.xxx] ACPI: Table Upgrade: install [SSDT-CUSTOM- SENSOR]

acpi_walk_namespace API

acpi_walk_namespace()는 ACPI 네임스페이스 트리를 깊이 우선(depth-first)으로 순회하면서, 지정된 타입의 객체를 만날 때마다 콜백 함수를 호출하는 ACPICA API입니다. 커널의 ACPI 서브시스템이 장치를 열거하고, 디버깅 도구가 네임스페이스를 탐색하고, 드라이버가 특정 장치를 검색할 때 핵심적으로 사용됩니다.

acpi_walk_namespace 사용법

/* 네임스페이스의 모든 디바이스를 순회하며 _HID 출력 */
static acpi_status print_device_callback(
    acpi_handle handle,
    u32 level,
    void *context,
    void **ret)
{
    struct acpi_device_info *info;
    acpi_status status;

    status = acpi_get_object_info(handle, &info);
    if (ACPI_FAILURE(status))
        return AE_OK;  /* 계속 순회 */

    if (info->valid & ACPI_VALID_HID)
        pr_info("Level %u: Device HID=%s\n",
                level, info->hardware_id.string);

    kfree(info);
    return AE_OK;  /* AE_OK = 계속, AE_CTRL_TERMINATE = 중단 */
}

/* 호출: \_SB 아래 모든 장치 순회 (최대 깊이 10) */
acpi_status status;
status = acpi_walk_namespace(
    ACPI_TYPE_DEVICE,      /* 장치 객체만 */
    ACPI_ROOT_OBJECT,      /* 루트(\_)부터 시작 */
    10,                    /* 최대 깊이 */
    print_device_callback, /* descending 콜백 */
    NULL,                  /* ascending 콜백 (선택) */
    NULL,                  /* context 데이터 */
    NULL                   /* 반환 값 */
);
if (ACPI_FAILURE(status))
    pr_err("Namespace walk failed: %s\n",
           acpi_format_exception(status));

acpi_evaluate_object 활용

/* 특정 ACPI 경로의 메서드/객체 평가 */
union acpi_object arg;
struct acpi_object_list arg_list;
struct acpi_buffer result = { ACPI_ALLOCATE_BUFFER, NULL };

/* 인자 준비: 정수 하나 */
arg.type = ACPI_TYPE_INTEGER;
arg.integer.value = 0x01;
arg_list.count = 1;
arg_list.pointer = &arg;

/* \_SB.PCI0._BBN (PCI 버스 번호) 평가 */
status = acpi_evaluate_object(NULL,   /* handle: NULL = 경로명 사용 */
    "\\_SB.PCI0._BBN",              /* 절대 경로 */
    NULL,                            /* 인자 없음 */
    &result);

if (ACPI_SUCCESS(status)) {
    union acpi_object *obj = result.pointer;
    if (obj->type == ACPI_TYPE_INTEGER)
        pr_info("PCI bus number: %lld\n", obj->integer.value);
    kfree(result.pointer);
}

/* acpi_evaluate_integer() — 정수 결과 간편 래퍼 */
unsigned long long value;
status = acpi_evaluate_integer(handle, "_STA", NULL, &value);
if (ACPI_SUCCESS(status))
    pr_info("_STA = 0x%llx\n", value);

/* acpi_get_handle() — 경로로 핸들 얻기 */
acpi_handle ec_handle;
status = acpi_get_handle(NULL, "\\_SB.PCI0.LPCB.EC0", &ec_handle);
if (ACPI_SUCCESS(status))
    pr_info("EC handle found\n");

콜백 함수 구현 패턴

/* 패턴 1: 특정 _HID 검색 후 중단 */
struct find_ctx {
    const char *target_hid;
    acpi_handle found;
};

static acpi_status find_by_hid(acpi_handle handle, u32 level,
                                void *ctx, void **ret)
{
    struct find_ctx *fctx = ctx;
    struct acpi_device_info *info;

    if (ACPI_FAILURE(acpi_get_object_info(handle, &info)))
        return AE_OK;

    if ((info->valid & ACPI_VALID_HID) &&
        !strcmp(info->hardware_id.string, fctx->target_hid)) {
        fctx->found = handle;
        kfree(info);
        return AE_CTRL_TERMINATE;  /* 찾았으면 즉시 중단 */
    }
    kfree(info);
    return AE_OK;
}

/* 패턴 2: descending + ascending 조합 (트리 구조 출력) */
static acpi_status enter_scope(acpi_handle h, u32 lvl,
                               void *c, void **r)
{
    char name[ACPI_NAMESEG_SIZE + 1];
    struct acpi_buffer buf = { sizeof(name), name };
    acpi_get_name(h, ACPI_SINGLE_NAME, &buf);
    pr_info("%*s%s {\n", lvl * 2, "", name);
    return AE_OK;
}
static acpi_status leave_scope(acpi_handle h, u32 lvl,
                               void *c, void **r)
{
    pr_info("%*s}\n", lvl * 2, "");
    return AE_OK;
}

/* 전체 네임스페이스 트리 출력 */
acpi_walk_namespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX,
                    enter_scope, leave_scope, NULL, NULL);

배터리/EC 인터페이스

노트북의 배터리 정보는 Embedded Controller(EC)의 RAM에 저장되며, ACPI 네임스페이스의 _BIF/_BIX(정적 정보)와 _BST(동적 상태) 메서드가 이를 읽어 OS에 전달합니다. 커널의 acpi_battery 드라이버가 이 메서드를 주기적으로 호출해 power_supply 프레임워크에 등록하고, /sys/class/power_supply/BAT0/을 통해 사용자 공간에 노출합니다.

_BST/_BIF ASL 구현

/* 배터리 장치 ASL (DSDT/SSDT에서 발췌) */
Device (BAT0)
{
    Name (_HID, EisaId ("PNP0C0A"))   /* Control Method Battery */
    Name (_UID, 0)
    Name (_PCL, Package () { \_SB })  /* 전원 소비자: 시스템 전체 */

    /* _STA: 배터리 존재 여부 */
    Method (_STA, 0, NotSerialized)
    {
        If (\_SB.PCI0.LPCB.EC0.ECAV)
        {
            If (\_SB.PCI0.LPCB.EC0.MBTS)  /* Main Battery Status */
            {
                Return (0x1F)   /* Present, Enabled, Functioning */
            }
        }
        Return (0x0F)       /* Not Present */
    }

    /* _BIF: 배터리 정적 정보 (13개 필드) */
    Method (_BIF, 0, NotSerialized)
    {
        Name (BPKG, Package (13)
        {
            0x00,           /* [0]  Power Unit: 0=mWh, 1=mAh */
            0xFFFFFFFF,     /* [1]  Design Capacity */
            0xFFFFFFFF,     /* [2]  Last Full Charge Capacity */
            0x01,           /* [3]  Battery Technology: Rechargeable */
            0xFFFFFFFF,     /* [4]  Design Voltage (mV) */
            0x00,           /* [5]  Design Capacity of Warning */
            0x00,           /* [6]  Design Capacity of Low */
            0x01,           /* [7]  Battery Capacity Granularity 1 */
            0x01,           /* [8]  Battery Capacity Granularity 2 */
            "Model",       /* [9]  Model Number */
            "",            /* [10] Serial Number */
            "LiP",         /* [11] Battery Type */
            "OEM"          /* [12] OEM Information */
        })

        /* EC에서 실제 값 읽기 */
        BPKG [1] = \_SB.PCI0.LPCB.EC0.BDCF  /* Design Capacity */
        BPKG [2] = \_SB.PCI0.LPCB.EC0.BFCF  /* Full Charge Cap */
        BPKG [4] = \_SB.PCI0.LPCB.EC0.BDVL  /* Design Voltage */

        Return (BPKG)
    }

    /* _BST: 배터리 동적 상태 (4개 필드) */
    Method (_BST, 0, NotSerialized)
    {
        Name (PKG, Package (4)
        {
            0x00,           /* [0] State: bit0=방전, bit1=충전, bit2=임계 */
            0xFFFFFFFF,     /* [1] Present Rate (mW 또는 mA) */
            0xFFFFFFFF,     /* [2] Remaining Capacity */
            0xFFFFFFFF      /* [3] Present Voltage (mV) */
        })

        PKG [0] = \_SB.PCI0.LPCB.EC0.BTST   /* Battery Status */
        PKG [1] = \_SB.PCI0.LPCB.EC0.BRAT   /* Rate */
        PKG [2] = \_SB.PCI0.LPCB.EC0.BRCA   /* Remaining */
        PKG [3] = \_SB.PCI0.LPCB.EC0.BVOL   /* Voltage */

        Return (PKG)
    }
}

acpi_battery 커널 드라이버

/* drivers/acpi/battery.c — 핵심 흐름 */

/* 1. 배터리 드라이버 등록 */
static struct acpi_driver acpi_battery_driver = {
    .name  = "battery",
    .ids   = battery_device_ids,   /* PNP0C0A */
    .ops   = {
        .add    = acpi_battery_add,
        .remove = acpi_battery_remove,
        .notify = acpi_battery_notify,
    },
};

/* 2. _BST 호출로 상태 읽기 */
static int acpi_battery_get_state(struct acpi_battery *battery)
{
    struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
    union acpi_object *bst;

    status = acpi_evaluate_object(battery->device->handle,
                                   "_BST", NULL, &buffer);
    bst = buffer.pointer;

    /* Package(4) 파싱 */
    battery->state        = bst->package.elements[0].integer.value;
    battery->rate_now     = bst->package.elements[1].integer.value;
    battery->capacity_now = bst->package.elements[2].integer.value;
    battery->voltage_now  = bst->package.elements[3].integer.value;

    kfree(buffer.pointer);
    return 0;
}

/* 3. EC 이벤트 처리 */
static void acpi_battery_notify(struct acpi_device *device, u32 event)
{
    struct acpi_battery *battery = acpi_driver_data(device);

    switch (event) {
    case ACPI_BATTERY_NOTIFY_STATUS:   /* 0x80 */
        acpi_battery_get_state(battery);
        break;
    case ACPI_BATTERY_NOTIFY_INFO:     /* 0x81 */
        acpi_battery_get_info(battery);
        break;
    }

    /* power_supply 프레임워크에 변경 알림 */
    power_supply_changed(battery->bat);
    /* → /sys/class/power_supply/BAT0/ 갱신 */
    /* → uevent → upower/systemd-logind 감지 */
}

/* 4. sysfs 매핑 */
/* /sys/class/power_supply/BAT0/status    → "Charging"/"Discharging"/"Full" */
/* /sys/class/power_supply/BAT0/capacity  → 0~100 (%) */
/* /sys/class/power_supply/BAT0/voltage_now → _BST[3] (µV) */
/* /sys/class/power_supply/BAT0/current_now → _BST[1] (µA) */

Platform Profile과 성능 정책

Platform Profile은 사용자에게 "저전력(quiet)", "균형(balanced)", "고성능(performance)" 같은 시스템 전체 성능 정책을 통합된 인터페이스로 제공하는 커널 프레임워크입니다. OEM 벤더별 ACPI _DSM 또는 WMI를 통해 실제 펌웨어 설정을 변경하며, /sys/firmware/acpi/platform_profile을 통해 사용자 공간에서 제어합니다.

platform_profile API

/* include/linux/platform_profile.h */

/* 정의된 프로파일 */
enum platform_profile_option {
    PLATFORM_PROFILE_LOW_POWER,       /* 저전력 */
    PLATFORM_PROFILE_COOL,            /* 조용한 (팬 최소) */
    PLATFORM_PROFILE_QUIET,           /* 소음 최소 */
    PLATFORM_PROFILE_BALANCED,        /* 균형 */
    PLATFORM_PROFILE_BALANCED_PERFORMANCE,  /* 균형-성능 */
    PLATFORM_PROFILE_PERFORMANCE,     /* 고성능 */
    PLATFORM_PROFILE_CUSTOM,          /* 사용자 정의 */
    PLATFORM_PROFILE_LAST,
};

/* 드라이버가 구현할 콜백 */
struct platform_profile_handler {
    unsigned long choices[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)];
    int (*profile_get)(struct platform_profile_handler *h,
                        enum platform_profile_option *profile);
    int (*profile_set)(struct platform_profile_handler *h,
                        enum platform_profile_option profile);
};

/* 등록/해제 */
int platform_profile_register(struct platform_profile_handler *h);
void platform_profile_remove(struct platform_profile_handler *h);

/* sysfs 인터페이스 */
/* /sys/firmware/acpi/platform_profile                → 현재 프로파일 */
/* /sys/firmware/acpi/platform_profile_choices         → 지원 프로파일 목록 */
/* echo "performance" > /sys/firmware/acpi/platform_profile */

/* 사용 예 */
$ cat /sys/firmware/acpi/platform_profile_choices
# low-power quiet balanced performance

$ cat /sys/firmware/acpi/platform_profile
# balanced

$ echo "performance" | sudo tee /sys/firmware/acpi/platform_profile
# performance

DYTC(Lenovo)/APMF(AMD) _DSM 예제

/* Lenovo DYTC (Dynamic Thermal Control) — drivers/platform/x86/thinkpad_acpi.c */

/* DYTC _DSM UUID */
static const guid_t dytc_guid =
    GUID_INIT(0xb23ba85d, 0xc8b7, 0x3542,
              0x88, 0xde, 0x8d, 0xe2,
              0x25, 0x38, 0x1a, 0xbc);

/* DYTC 명령: 프로파일 설정 */
enum dytc_cmd {
    DYTC_CMD_QUERY  = 0,  /* 현재 상태 조회 */
    DYTC_CMD_SET    = 1,  /* 프로파일 설정 */
    DYTC_CMD_RESET  = 2,  /* 기본값 복원 */
};

/* DYTC → platform_profile 매핑 */
static int dytc_profile_set(struct platform_profile_handler *h,
                             enum platform_profile_option profile)
{
    int dytc_mode;

    switch (profile) {
    case PLATFORM_PROFILE_LOW_POWER:
        dytc_mode = DYTC_MODE_LOWPOWER;
        break;
    case PLATFORM_PROFILE_BALANCED:
        dytc_mode = DYTC_MODE_BALANCED;
        break;
    case PLATFORM_PROFILE_PERFORMANCE:
        dytc_mode = DYTC_MODE_PERFORM;
        break;
    default:
        return -EOPNOTSUPP;
    }

    /* _DSM 호출로 펌웨어에 모드 전달 */
    return dytc_command(DYTC_CMD_SET, dytc_mode);
}

/* ===== AMD APMF (Platform Management Framework) ===== */
/* drivers/platform/x86/amd/pmf/ */

/* APMF는 SMU(System Management Unit)와 통신 */
/* _DSM을 통해 thermal policy, fan curve, power limit 제어 */

/* APMF 프로파일 매핑 예 */
/* quiet      → TDP 15W, 팬 2000 RPM max */
/* balanced   → TDP 25W, 팬 3500 RPM max */
/* performance→ TDP 35W, 팬 5000 RPM max */

/* power-profiles-daemon 통합 */
/* GNOME/KDE 설정 → power-profiles-daemon */
/*   → /sys/firmware/acpi/platform_profile에 기록 */
/*   → 벤더 드라이버 → _DSM/WMI → 펌웨어/EC */

참고자료

공식 규격 및 표준

• ACPI Specification 6.5 — UEFI Forum이 관리하는 ACPI 최신 공식 규격입니다
• UEFI Forum — ACPI Resources — ACPI 규격 다운로드 및 관련 리소스 페이지입니다
• Intel ACPICA Project — Intel이 유지보수하는 OS 독립적 ACPI 참조 구현체(ACPICA) 공식 페이지입니다

커널 문서

• ACPI Support — Kernel Documentation — 커널 공식 ACPI 가이드입니다
• ACPI Based Device Enumeration — ACPI 기반 장치 열거(Enumeration) 방식을 설명합니다
• ACPI Debug — Method Tracing — AML 메서드 트레이싱을 통한 ACPI 디버깅 방법입니다
• System Sleep States — ACPI S-state 기반 시스템 절전 상태 관리를 설명합니다
• CPPC Sysfs Interface — ACPI CPPC(Collaborative Processor Performance Control) sysfs 인터페이스입니다

LWN 기사

• A guide to ACPI in the kernel — 커널 ACPI 서브시스템의 전체 구조를 개괄합니다 (2009)
• ACPI, PCI, and ... Device Tree? — ACPI와 Device Tree의 관계를 논의합니다 (2013)
• ACPI for ARM? — ARM 플랫폼의 ACPI 도입 논쟁을 다룹니다 (2013)
• ACPI and Device Tree — ARM64에서 ACPI와 DT의 공존 방식을 설명합니다 (2014)
• ACPI and the IORT — I/O Remapping Table(IORT)과 IOMMU 연동을 다룹니다 (2016)

커널 소스 코드

• drivers/acpi/ — 리눅스 커널 ACPI 서브시스템 전체 소스 코드입니다
• drivers/acpi/acpica/ — Intel ACPICA 참조 구현체 소스입니다
• include/acpi/ — ACPI 관련 커널 헤더 파일입니다
• drivers/acpi/scan.c — ACPI 네임스페이스 스캔 및 장치 열거 핵심 코드입니다

컨퍼런스 발표 및 기술 자료

• Linux Plumbers Conference — ACPI and the Device Model — ACPI와 리눅스 디바이스 모델 통합을 설명하는 발표입니다
• ACPICA Documentation — ACPICA 프로젝트의 프로그래머 레퍼런스 및 사용자 가이드입니다

관련 문서

ACPI와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• 부팅 과정 — ACPI 초기화
• UEFI — UEFI와 ACPI
• 전원 관리 (PM) — ACPI 전원 관리
• Device Tree — Device Tree와의 비교