요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
=====================================
Devicetree Sources (DTS) Coding Style
=====================================
When writing Devicetree Sources (DTS) please observe below guidelines. They
should be considered complementary to any rules expressed already in
the Devicetree Specification and the dtc compiler (including W=1 and W=2
builds).
Individual architectures and subarchitectures can define additional rules,
making the coding style stricter.
Naming and Valid Characters
---------------------------
The Devicetree Specification allows a broad range of characters in node
and property names, but this coding style narrows the range down to achieve
better code readability.
1. Node and property names can use only the following characters:
* Lowercase characters: [a-z]
* Digits: [0-9]
* Dash: -
2. Labels can use only the following characters:
* Lowercase characters: [a-z]
* Digits: [0-9]
* Underscore: _
3. Unless a bus defines differently, unit addresses shall use lowercase
hexadecimal digits, without leading zeros (padding).
4. Hex values in properties, e.g. "reg", shall use lowercase hex. The address
part can be padded with leading zeros.
Example::
gpi_dma2: dma-controller@a00000 {
compatible = "qcom,sm8550-gpi-dma", "qcom,sm6350-gpi-dma";
reg = <0x0 0x00a00000 0x0 0x60000>;
}
Order of Nodes
--------------
1. Nodes on any bus, thus using unit addresses for children, shall be
ordered by unit address in ascending order.
Alternatively for some subarchitectures, nodes of the same type can be
grouped together, e.g. all I2C controllers one after another even if this
breaks unit address ordering.
2. Nodes without unit addresses shall be ordered alpha-numerically by the node
name. For a few node types, they can be ordered by the main property, e.g.
pin configuration states ordered by value of "pins" property.
3. When extending nodes in the board DTS via &label, the entries shall be
ordered either alpha-numerically or by keeping the order from DTSI, where
the choice depends on the subarchitecture.
The above-described ordering rules are easy to enforce during review, reduce
chances of conflicts for simultaneous additions of new nodes to a file and help
in navigating through the DTS source.
Example::
/* SoC DTSI */
/ {
cpus {
/* ... */
};
psci {
/* ... */
};
soc@0 {
dma: dma-controller@10000 {
/* ... */
};
clk: clock-controller@80000 {
/* ... */
};
};
};
/* Board DTS - alphabetical order */
&clk {
/* ... */
};
&dma {
/* ... */
};
/* Board DTS - alternative order, keep as DTSI */
&dma {
/* ... */
};
&clk {
/* ... */
};
Order of Properties in Device Node
----------------------------------
The following order of properties in device nodes is preferred:
1. "compatible"
2. "reg"
3. "ranges"
4. Standard/common properties (defined by common bindings, e.g. without
vendor-prefixes)
5. Vendor-specific properties
6. "status" (if applicable)
7. Child nodes, where each node is preceded with a blank line
The "status" property is by default "okay", thus it can be omitted.
The above-described ordering follows this approach:
1. Most important properties start the node: compatible then bus addressing to
match unit address.
2. Each node will have common properties in similar place.
3. Status is the last information to annotate that device node is or is not
finished (board resources are needed).
The individual properties inside each group shall use natural sort order by
the property name.
Example::
/* SoC DTSI */
device_node: device-class@6789abc {
compatible = "vendor,device";
reg = <0x0 0x06789abc 0x0 0xa123>;
ranges = <0x0 0x0 0x06789abc 0x1000>;
#dma-cells = <1>;
clocks = <&clock_controller 0>, <&clock_controller 1>;
clock-names = "bus", "host";
#address-cells = <1>;
#size-cells = <1>;
vendor,custom-property = <2>;
status = "disabled";
child_node: child-class@100 {
reg = <0x100 0x200>;
/* ... */
};
};
/* Board DTS */
&device_node {
vdd-0v9-supply = <&board_vreg1>;
vdd-1v8-supply = <&board_vreg4>;
vdd-3v3-supply = <&board_vreg2>;
vdd-12v-supply = <&board_vreg3>;
status = "okay";
}
Indentation and wrapping
------------------------
1. Use indentation and wrap lines according to
Documentation/process/coding-style.rst.
2. Each entry in arrays with multiple cells, e.g. "reg" with two IO addresses,
shall be enclosed in <>.
3. For arrays spanning across lines, it is preferred to split on item boundary
and align the continued entries with opening < from the first line.
Usually avoid splitting individual items unless they significantly exceed
line wrap limit.
Example::
thermal-sensor@c271000 {
compatible = "qcom,sm8550-tsens", "qcom,tsens-v2";
reg = <0x0 0x0c271000 0x0 0x1000>,
<0x0 0x0c222000 0x0 0x1000>;
/* Lines exceeding coding style line wrap limit: */
interconnects = <&aggre1_noc MASTER_USB3_0 0 &mc_virt SLAVE_EBI1 0>,
<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_USB3_0 0>;
};
Organizing DTSI and DTS
-----------------------
The DTSI and DTS files shall be organized in a way representing the common,
reusable parts of hardware. Typically, this means organizing DTSI and DTS files
into several files:
1. DTSI with contents of the entire SoC, without nodes for hardware not present
on the SoC.
2. If applicable: DTSI with common or re-usable parts of the hardware, e.g.
entire System-on-Module.
3. DTS representing the board.
Hardware components that are present on the board shall be placed in the
board DTS, not in the SoC or SoM DTSI. A partial exception is a common
external reference SoC input clock, which could be coded as a fixed-clock in
the SoC DTSI with its frequency provided by each board DTS.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
DTS 이름과 허용 문자
1-46Devicetree Source(DTS)를 작성할 때 이 지침을 따라야 합니다. 이 규칙은 Devicetree Specification과 `dtc` compiler가 이미 표현하는 규칙, 즉 `W=1` 및 `W=2` build를 포함한 규칙을 보완합니다. 개별 architecture와 subarchitecture는 더 엄격한 추가 규칙을 정의할 수 있습니다.
Devicetree Specification은 node와 property 이름에 넓은 문자 범위를 허용하지만, 이 coding style은 code 가독성을 높이기 위해 범위를 좁힙니다. Node와 property 이름에는 소문자 `[a-z]`, 숫자 `[0-9]`, dash `-`만 사용할 수 있습니다. Label에는 소문자 `[a-z]`, 숫자 `[0-9]`, underscore `_`만 사용할 수 있습니다.
Bus가 다르게 정의하지 않는 한 unit address는 leading zero padding 없이 소문자 hexadecimal digit을 사용해야 합니다. `reg` 같은 property의 hex 값도 소문자 hex를 사용하며, 이때 address 부분은 leading zero로 padding할 수 있습니다.
Node/property와 label에서 허용되는 문자를 구분합니다.
gpi_dma2: dma-controller@a00000 {
compatible = "qcom,sm8550-gpi-dma", "qcom,sm6350-gpi-dma";
reg = <0x0 0x00a00000 0x0 0x60000>;
}
Node 순서
47-111Child에 unit address를 사용하는 모든 bus의 node는 unit address 오름차순으로 정렬해야 합니다. 일부 subarchitecture에서는 이 순서를 깨더라도 같은 종류의 node를 한데 묶을 수 있습니다. 예를 들어 모든 I2C controller를 연속해서 둘 수 있습니다.
Unit address가 없는 node는 node 이름의 영숫자 순으로 정렬해야 합니다. 일부 node 종류는 주 property를 기준으로 정렬할 수 있습니다. 예를 들어 pin configuration state는 `pins` property 값 순으로 둘 수 있습니다.
Board DTS에서 `&label`로 node를 확장할 때 entry는 영숫자 순으로 정렬하거나 DTSI의 순서를 유지해야 하며, 어느 방식을 쓸지는 subarchitecture에 따릅니다. 이러한 규칙은 review에서 쉽게 강제할 수 있고, 같은 파일에 node를 동시에 추가할 때 conflict 가능성을 줄이며 DTS source 탐색을 돕습니다.
Node의 unit address 유무와 board 확장 여부에 따라 적용할 순서를 나타냅니다.
/* SoC DTSI */
/ {
cpus {
/* ... */
};
psci {
/* ... */
};
soc@0 {
dma: dma-controller@10000 {
/* ... */
};
clk: clock-controller@80000 {
/* ... */
};
};
};
/* Board DTS - alphabetical order */
&clk {
/* ... */
};
&dma {
/* ... */
};
/* Board DTS - alternative order, keep as DTSI */
&dma {
/* ... */
};
&clk {
/* ... */
};
Device node의 property 순서
112-170Device node property의 권장 순서는 `compatible`, `reg`, `ranges`, 표준/common property, vendor-specific property, 해당하는 경우 `status`, 그리고 각 node 앞에 blank line을 둔 child node입니다. 표준/common property는 vendor prefix 없이 common binding에서 정의된 속성을 뜻합니다.
`status`의 기본값은 `okay`이므로 생략할 수 있습니다. 이 순서는 가장 중요한 `compatible`과 unit address에 맞추는 bus addressing을 node 앞에 두고, 모든 node에서 common property를 비슷한 위치에 배치하며, board resource가 필요한지를 표시하는 최종 정보인 `status`를 마지막에 두려는 방식입니다.
각 group 안의 개별 property는 property 이름의 natural sort order를 따라야 합니다.
권장 property group 순서를 review 가능한 단계로 정리합니다.
/* SoC DTSI */
device_node: device-class@6789abc {
compatible = "vendor,device";
reg = <0x0 0x06789abc 0x0 0xa123>;
ranges = <0x0 0x0 0x06789abc 0x1000>;
#dma-cells = <1>;
clocks = <&clock_controller 0>, <&clock_controller 1>;
clock-names = "bus", "host";
#address-cells = <1>;
#size-cells = <1>;
vendor,custom-property = <2>;
status = "disabled";
child_node: child-class@100 {
reg = <0x100 0x200>;
/* ... */
};
};
/* Board DTS */
&device_node {
vdd-0v9-supply = <&board_vreg1>;
vdd-1v8-supply = <&board_vreg4>;
vdd-3v3-supply = <&board_vreg2>;
vdd-12v-supply = <&board_vreg3>;
status = "okay";
}
들여쓰기와 줄바꿈
171-193들여쓰기와 줄바꿈은 `Documentation/process/coding-style.rst`를 따릅니다. 두 IO address를 담는 `reg`처럼 여러 cell을 가진 array에서는 각 entry를 `<>`로 감싸야 합니다.
여러 줄에 걸친 array는 item 경계에서 나누고 이어지는 entry를 첫 줄의 여는 `<`에 맞추는 방식을 권장합니다. 개별 item이 line wrap 제한을 크게 넘지 않는 한 item 자체를 나누는 것은 피합니다.
thermal-sensor@c271000 {
compatible = "qcom,sm8550-tsens", "qcom,tsens-v2";
reg = <0x0 0x0c271000 0x0 0x1000>,
<0x0 0x0c222000 0x0 0x1000>;
/* Lines exceeding coding style line wrap limit: */
interconnects = <&aggre1_noc MASTER_USB3_0 0 &mc_virt SLAVE_EBI1 0>,
<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_USB3_0 0>;
};
DTSI와 DTS 구성
194-210DTSI와 DTS 파일은 hardware의 공통되고 재사용 가능한 부분을 나타내도록 구성해야 합니다. 일반적으로 전체 SoC 내용을 담되 SoC에 없는 hardware node는 포함하지 않는 DTSI, 해당하는 경우 System-on-Module 전체처럼 공통 또는 재사용 가능한 hardware 부분을 담는 DTSI, 그리고 board를 나타내는 DTS로 나눕니다.
Board에 존재하는 hardware component는 SoC나 SoM DTSI가 아니라 board DTS에 두어야 합니다. 부분적인 예외는 공통 external reference SoC input clock입니다. 이를 SoC DTSI에 `fixed-clock`으로 작성하고 각 board DTS가 frequency를 제공할 수 있습니다.
공통 hardware에서 구체적인 board 구성으로 내려가는 재사용 계층을 나타냅니다.
요약과 해설
dts-coding-style.rst:1-210Review conflict를 줄이고 일관된 DTS source를 만드는 coding style을 설명합니다.