On 06/11/2013 18:32, Jason Cooper :
Signed-off-by: Jason Cooper <jason@xxxxxxxxxxxxxx>
---
All,
Since I've now had to answer this question a couple of times, I thought it
might be worth trying to put it in a document. I don't like long documents, so
this is pretty concise, and most likely wrong. Hence, RFC. :)
I also dislike quoting people from my imperfect memory, much better to have an
agreed upon document we can point people towards.
thx,
Jason.
.../devicetree/bindings/submitting-patches.txt | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/submitting-patches.txt
diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt
new file mode 100644
index 000000000000..5a84d5ebb0f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/submitting-patches.txt
@@ -0,0 +1,52 @@
+
+ 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
+ and clearly labelled as such. For example:
+
+ [PATCH X/Y] dt: binding: mvebu mbus driver
+
+ This makes the binding portion easy to find among large patch series.
+
+ 2) Submit the entire series to the devicetree mailinglist at
This is not what I understood.
It seems that we said that only the patch that was containing the
binding documentation have to be sent to the devicetree mainling-list
(but this patch being part of a patch series anyway). This way the
devicetree maintainers would not have to deal with the patch review
process, even if they can have a look to the code source on the
mailing-list archive if they need to.
Someone to clarify?
+ devicetree@xxxxxxxxxxxxxxx
+
+II. For sub-system 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) 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.
+
+ 3) For a series going though multiple trees, the binding patch should be
+ kept with the driver using the binding.
+
+III. General binding rules
+
+ 1) Don't hold up a binding because it isn't perfect.
+
+ 2) Use specific compatible strings so that if we need to add a feature (DMA)
+ in the future, we can create a new compatible string.
+
+ 3) Ideally, all bindings receive sufficient review. In the real world, we
+ need to prioritize. Bindings for a specific block of IP aren't as
+ critical as a binding for a common subsystem, like PCI.
+
+ 4) Don't submit bindings for staging or unstable. That will be decided by
+ the devicetree maintainers *after* discussion on the mailinglist.
+
+IV. Notes
+
+ 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.
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
