DT에 적었다고 드라이버 초기화가 끝난 것은 아닙니다
- 펌웨어가 DTB를 전달합니다
커널은 메모리·CPU·장치 연결 정보를 해석합니다.
버스와 노드 규칙에 맞춰 device가 만들어집니다.
- driver와 match합니다
compatible 목록 등 해당 버스의 매칭 규칙을 사용합니다.
probe가 장치 자원을 요청합니다.
- probe에서 의존성을 확인합니다
MMIO·IRQ·clock·regulator·reset 등 실제 필요한 자원을 확보합니다.
준비된 경우 하드웨어와 subsystem을 초기화합니다.
- 사용 가능한 장치
driver가 공개한 인터페이스와 전원 관리 경로가 동작합니다.
화살표는 device 생성·driver binding·초기화의 흐름입니다. 모든 DT 노드가 같은 방식의 platform device나 /dev 파일 하나를 만든다는 뜻은 아닙니다.
DTB 전달 레지스터도 아키텍처마다 다릅니다. AArch32 부팅 예제의 r2를 AArch64의 x2로 기계적으로 바꾸면 틀립니다. AArch64 부팅의 DTB 주소는 x0에 전달됩니다. AArch64 진입 레지스터 Device Tree 사용 모델
reg의 숫자는 부모 버스 문맥을 읽어야 합니다
/* 부모 버스가 #address-cells=<1>, #size-cells=<1>인 교육용 예 */
example@1000 {
compatible = "example,teaching-device";
reg = <0x1000 0x100>;
status = "okay";
};| 표현 | 의미 |
|---|---|
| example@1000 | 노드 이름과 unit address입니다. driver의 C 함수 이름을 부르는 문장이 아닙니다. |
| compatible | 해당 장치가 따르는 programming model을 식별합니다. 실제 장치는 정식 binding에 맞는 문자열을 사용해야 합니다. |
| reg | 이 예의 부모 cell 규칙에서 버스 주소 0x1000, 길이 0x100입니다. 부모의 ranges 등에 의해 CPU 주소로 변환될 수 있습니다. |
| status | 노드의 사용 가능 상태를 표현합니다. 이것만으로 clock이 켜지거나 probe가 성공하지는 않습니다. |
이 예는 가상의 binding이므로 제품 DT에 복사할 설정이 아닙니다. interrupt cell도 controller의 binding과 #interrupt-cells를 따라 읽습니다. 숫자 하나를 Linux IRQ 번호라고 단정하지 않습니다. DT cell과 주소 규칙 커널의 DT 해석 API
EPROBE_DEFER는 의존 장치를 나중에 기다리겠다는 결과입니다
clk = devm_clk_get(dev, "bus");
if (IS_ERR(clk))
return dev_err_probe(dev, PTR_ERR(clk), "bus clock unavailable\n");실제 API를 사용하는 짧은 형태의 예입니다. clk은 단순 NULL만 검사하는 포인터가 아닙니다. IS_ERR로 error pointer를 확인하고 PTR_ERR로 오류 번호를 읽습니다. provider가 아직 준비되지 않아 -EPROBE_DEFER가 돌아오면 그 값을 보존해 driver core가 재시도할 수 있도록 합니다. 모든 오류를 -EINVAL로 바꾸면 defer의 의미가 사라집니다.
devm은 자원 해제를 device 수명에 연결하는 관리 방식입니다. clock이 켜져 있는지, DMA가 끝났는지, worker가 종료됐는지까지 자동으로 보장하는 말은 아닙니다. probe가 실패하거나 remove가 진행될 때 실행 중인 하드웨어·비동기 작업을 멈추는 순서가 필요합니다. dev_err_probe와 device 관리 managed resource의 범위
로그와 실제 실행 중인 DT를 같이 봅니다
- 빌드한 DTS와 부트로더가 실제 선택한 DTB·overlay가 같은지 확인합니다.
- 노드의 status, compatible, reg·interrupt·clock·reset의 binding을 확인합니다.
- driver가 빌트인인지 module인지, 해당 CONFIG가 활성인지 확인합니다.
- provider의 probe 실패나 defer가 먼저 발생하지 않았는지 확인합니다.
- device가 bind된 뒤에도 runtime PM과 장치 자체의 상태를 따로 확인합니다.
기존 Device Tree 분석이 compatible 매칭과 자료 구조를 설명한다면, 이 글은 그 이후 “왜 probe가 끝나지 않는가”를 추적하는 데 초점을 둡니다.