device tree

FDT, live node, 장치 등록의 경계

이 글의 두 대표 함수는 이미 만들어진 live device tree를 사용한다. flat FDT에서 device_node tree를 만드는 unflatten_device_tree()는 drivers/of/fdt.c의 앞 단계다. of_platform_populate()는 그 live tree를 순회하여 장치 생성 경로에 들어가고, of_find_node_by_path()는 경로 조회만 한다.

소스 코드 위치

Linux v6.6: drivers/of/base.c
Linux v6.6: drivers/of/platform.c
Linux v6.6: drivers/of/fdt.c
Linux v6.6: include/linux/of.h

대표 코드

int of_platform_populate(struct device_node *root,
			const struct of_device_id *matches,
			const struct of_dev_auxdata *lookup,
			struct device *parent)
{
	struct device_node *child;
	int rc = 0;

	root = root ? of_node_get(root) : of_find_node_by_path("/");
	if (!root)
		return -EINVAL;

	pr_debug("%s()\n", __func__);
	pr_debug(" starting at: %pOF\n", root);

	device_links_supplier_sync_state_pause();
	for_each_child_of_node(root, child) {
		rc = of_platform_bus_create(child, matches, lookup, parent, true);
		if (rc) {
			of_node_put(child);
			break;
		}
	}
	device_links_supplier_sync_state_resume();

	of_node_set_flag(root, OF_POPULATED_BUS);

	of_node_put(root);
	return rc;
}

static inline struct device_node *of_find_node_by_path(const char *path)
{
	return of_find_node_opts_by_path(path, NULL);
}

두 대표 함수가 하는 일과 하지 않는 일

of_platform_populate()와 of_find_node_by_path()는 순차 호출 체인이 아니다. populate가 root 인자로 NULL을 받았을 때 경로 "/"를 조회할 수 있지만, 호출자가 다른 path를 찾는 wrapper는 독립적으로 쓸 수 있다.

base.c path lookup 구현 · platform.c:494–523

device_node 참조와 장치 객체의 소유권

경로 조회가 돌려준 node 참조, populate 내부가 임시 확보한 root 참조, 자식 순회 중의 참조는 서로 다른 소유권이다.

참조 계약: of.h node ref API · populate 반복

이 고정 버전의 of_platform_device_create_pdata()는 비활성/이미 populated 노드뿐 아니라 할당·등록 실패에도 NULL을 반환한다. 이를 호출한 of_platform_bus_create()의 !dev 분기는 0을 반환한다. 따라서 모든 장치 생성 실패가 음수 rc로 전파된다고 해석하면 안 된다. 반환 0과 OF_POPULATED_BUS만으로 장치 생성 완료를 판단하지 않고 실제 객체와 로그를 확인한다. 생성 helper · bus 생성의 NULL 처리

성공·건너뜀·오류를 구별하는 상태표

한 함수가 0을 반환해도 모든 DT node가 장치로 바뀌거나 probe가 끝난 것은 아니다. 먼저 live node 존재와 장치 등록 여부를 분리한다.

두 API에서 지켜야 할 경계

근거: populate · path wrapper · path lookup 구현

읽기 전용으로 단계별 확인

아래 경로는 해당 기능이 켜진 보드에서만 나타난다. 실제 DT 내용과 Kconfig·driver 로그를 함께 기록해야 원인 단계가 구분된다. 전역 tracefs tracer/filter를 바꾸지 않는다.

동적 추적이 필요하면 테스트 환경에서 사용 가능한 event/function을 먼저 확인하고 범위를 협의한다. 시스템 전체 current_tracer·set_ftrace_filter를 예제로 덮어쓰지 않는다.

보드에서 추가로 확인할 질문

• 사용한 FDT와 Kconfig에서 어떤 node가 live tree에 존재하며 status와 compatible은 무엇인가?
• 선택한 root 아래 각 child가 strict compatible·skip table·already-populated 조건 중 어디에서 걸리는가?
• root 부재의 -EINVAL과, 반환 0인데도 일부 장치가 없는 경우를 구분했는가? 생성 helper의 NULL 반환과 root flag를 각각 확인했는가?
• 찾은 node의 참조는 어느 호출자가 of_node_put()하며, 같은 node에 대응하는 device와 driver link는 별도로 존재하는가?
• device는 있는데 driver가 없다면 match 부재, probe 실패, deferred probe 중 어느 로그가 근거인가?