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