Commit | Line | Data |
---|---|---|
2a933001 JC |
1 | |
2 | Submitting devicetree (DT) binding patches | |
3 | ||
4 | I. For patch submitters | |
5 | ||
8c27ceff | 6 | 0) Normal patch submission rules from Documentation/process/submitting-patches.rst |
2a933001 JC |
7 | applies. |
8 | ||
9 | 1) The Documentation/ portion of the patch should be a separate patch. | |
10 | ||
11 | 2) Submit the entire series to the devicetree mailinglist at | |
12 | ||
13 | devicetree@vger.kernel.org | |
14 | ||
d1e9fa98 MP |
15 | and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify |
16 | all of the DT maintainers. | |
17 | ||
ef0b97e3 JMC |
18 | 3) The Documentation/ portion of the patch should come in the series before |
19 | the code implementing the binding. | |
20 | ||
10638a4e PW |
21 | 4) Any compatible strings used in a chip or board DTS file must be |
22 | previously documented in the corresponding DT binding text file | |
23 | in Documentation/devicetree/bindings. This rule applies even if | |
24 | the Linux device driver does not yet match on the compatible | |
25 | string. [ checkpatch will emit warnings if this step is not | |
26 | followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 | |
27 | ("checkpatch: add DT compatible string documentation checks"). ] | |
28 | ||
29 | 5) The wildcard "<chip>" may be used in compatible strings, as in | |
30 | the following example: | |
31 | ||
32 | - compatible: Must contain '"nvidia,<chip>-pcie", | |
33 | "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ... | |
34 | ||
35 | As in the above example, the known values of "<chip>" should be | |
36 | documented if it is used. | |
37 | ||
38 | 6) If a documented compatible string is not yet matched by the | |
39 | driver, the documentation should also include a compatible | |
40 | string that is matched by the driver (as in the "nvidia,tegra20-pcie" | |
41 | example above). | |
42 | ||
43 | ||
2a933001 JC |
44 | II. For kernel maintainers |
45 | ||
46 | 1) If you aren't comfortable reviewing a given binding, reply to it and ask | |
47 | the devicetree maintainers for guidance. This will help them prioritize | |
48 | which ones to review and which ones are ok to let go. | |
49 | ||
50 | 2) For driver (not subsystem) bindings: If you are comfortable with the | |
51 | binding, and it hasn't received an Acked-by from the devicetree | |
52 | maintainers after a few weeks, go ahead and take it. | |
53 | ||
54 | Subsystem bindings (anything affecting more than a single device) | |
55 | then getting a devicetree maintainer to review it is required. | |
56 | ||
57 | 3) For a series going though multiple trees, the binding patch should be | |
58 | kept with the driver using the binding. | |
59 | ||
60 | III. Notes | |
61 | ||
62 | 0) Please see ...bindings/ABI.txt for details regarding devicetree ABI. | |
63 | ||
64 | 1) This document is intended as a general familiarization with the process as | |
65 | decided at the 2013 Kernel Summit. When in doubt, the current word of the | |
66 | devicetree maintainers overrules this document. In that situation, a patch | |
67 | updating this document would be appreciated. |