On Thu, Nov 07, 2013 at 12:42:12PM +0100, Nicolas Ferre wrote: > On 06/11/2013 18:32, Jason Cooper : > >Signed-off-by: Jason Cooper <ja...@lakedaemon.net> > >--- > >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.
And that is the exact reason I wrote this doc. ;-) Mark Rutland said on Friday during the Q&A portion of the DT talk that he wanted to be able to refer to the code changes that went with the binding doc patch. I raised my hand and pointed to the elephant in the room, that this was the exact opposite of what was decided during the mini-summit. Grant said to send the whole series since he has better filters now for finding the binding documentation changes. Since he isn't the only reviewer, I came up with the 'dt: binding: ...' subject line to make the patch easier to find and review. Long story short, we changed our mind on the last day, and as I said in the comment section, I don't like quoting others from my imperfect memory. So, I'd like to have an agreed upon doc. > Someone to clarify? Please. thx, Jason. > >+ devicetree@vger.kernel.org > >+ > >+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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
