2013-12-17 23:59:40 +07:00
|
|
|
|
|
|
|
Submitting devicetree (DT) binding patches
|
|
|
|
|
|
|
|
I. For patch submitters
|
|
|
|
|
|
|
|
0) Normal patch submission rules from Documentation/SubmittingPatches
|
|
|
|
applies.
|
|
|
|
|
|
|
|
1) The Documentation/ portion of the patch should be a separate patch.
|
|
|
|
|
|
|
|
2) Submit the entire series to the devicetree mailinglist at
|
|
|
|
|
|
|
|
devicetree@vger.kernel.org
|
|
|
|
|
2015-03-05 22:53:11 +07:00
|
|
|
and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify
|
|
|
|
all of the DT maintainers.
|
|
|
|
|
2014-10-10 01:24:07 +07:00
|
|
|
3) The Documentation/ portion of the patch should come in the series before
|
|
|
|
the code implementing the binding.
|
|
|
|
|
2015-01-31 05:11:04 +07:00
|
|
|
4) Any compatible strings used in a chip or board DTS file must be
|
|
|
|
previously documented in the corresponding DT binding text file
|
|
|
|
in Documentation/devicetree/bindings. This rule applies even if
|
|
|
|
the Linux device driver does not yet match on the compatible
|
|
|
|
string. [ checkpatch will emit warnings if this step is not
|
|
|
|
followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864
|
|
|
|
("checkpatch: add DT compatible string documentation checks"). ]
|
|
|
|
|
|
|
|
5) The wildcard "<chip>" may be used in compatible strings, as in
|
|
|
|
the following example:
|
|
|
|
|
|
|
|
- compatible: Must contain '"nvidia,<chip>-pcie",
|
|
|
|
"nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
|
|
|
|
|
|
|
|
As in the above example, the known values of "<chip>" should be
|
|
|
|
documented if it is used.
|
|
|
|
|
|
|
|
6) If a documented compatible string is not yet matched by the
|
|
|
|
driver, the documentation should also include a compatible
|
|
|
|
string that is matched by the driver (as in the "nvidia,tegra20-pcie"
|
|
|
|
example above).
|
|
|
|
|
|
|
|
|
2013-12-17 23:59:40 +07:00
|
|
|
II. For kernel maintainers
|
|
|
|
|
|
|
|
1) If you aren't comfortable reviewing a given binding, reply to it and ask
|
|
|
|
the devicetree maintainers for guidance. This will help them prioritize
|
|
|
|
which ones to review and which ones are ok to let go.
|
|
|
|
|
|
|
|
2) For driver (not subsystem) bindings: If you are comfortable with the
|
|
|
|
binding, and it hasn't received an Acked-by from the devicetree
|
|
|
|
maintainers after a few weeks, go ahead and take it.
|
|
|
|
|
|
|
|
Subsystem bindings (anything affecting more than a single device)
|
|
|
|
then getting a devicetree maintainer to review it is required.
|
|
|
|
|
|
|
|
3) For a series going though multiple trees, the binding patch should be
|
|
|
|
kept with the driver using the binding.
|
|
|
|
|
|
|
|
III. Notes
|
|
|
|
|
|
|
|
0) Please see ...bindings/ABI.txt for details regarding devicetree ABI.
|
|
|
|
|
|
|
|
1) This document is intended as a general familiarization with the process as
|
|
|
|
decided at the 2013 Kernel Summit. When in doubt, the current word of the
|
|
|
|
devicetree maintainers overrules this document. In that situation, a patch
|
|
|
|
updating this document would be appreciated.
|